Microservices have since May 2011 have been touted as the way to go yet what does it actually meant to developers? Is it hype or is there something to it?
In this article we examine some of the pros and cons associated with not just this approach but its underlying principles.
A software development approach that is similar to a SOA (service-oriented architecture) style, microservices continue to challenge the concept of big build solutions.
So what’s involved?
- Developers choices
[read more=”Read more” less=”Read less”]
Have a hammer, see everything as a nail
Your favourite tool
If you speak Spanish, you will tend to go on holidays to places that speak Spanish, rather than places where you don’t speak a word.
It’s not that you can’t or won’t but you will tend to move towards things you’re comfortable with.
You go to college and you learn a programming language. Whichever programming language your course teaches is the language you will probably favour for the rest of your life.
When I first attended college, C and Cobol (Common Object Business Oriented Language) were the primary languages.
Why Cobol? It was huge in banks and it was before the Millennium bug. Cobol was a very employable language at the time.
Yet, the lecturers at the time forced the students to learn programming through Pseudocode!
Pseudocode is not a programming language, you couldn’t program in it.
Instead you write chunks of logic which made sense to humans and taught you the principles of programming not just the specifics of one language.
It teaches the students to program in every language and not be focused on the nuances and limitations of one language.
Don’t get me wrong, you could start by learning PHP and become a great programmer.
That said, if you face a challenge your natural default choice will be to see challenges solved by PHP first.
Microservices are a choice. Knowing the hows and whys and if you’ve developed like this before it will be natural to lean into it.
Planning ahead and lack thereof
Choice of language
As a programmer you’re asked to build a reporting system. There’s a database set up already and all you need to do is get the data.
- If you’re comfy with web languages, PHP or ASP.NET will be your lean to.
- Prefer a more hardcore solution you might go Java, C++, C#.
- More of a scripting fan? Use HTML, CSS and Perl, Python, PowerScript or VBScript.
- Eclectic and the more adventurous might use Object Oriented COBOL, F#, PostScript, TCL, Prolog, Groovy, Assembly or LISP.
All of these approaches work. You can build great solutions using all these languages each with their own pros and cons.
The more important question has nothing to do with the programmer.
Who is going to look after this code on an ongoing basis?
Most programmers will default to thinking, if I write it, I’m responsible for it.
Yet if it’s someone other than you because the programmer leaves the company everyone has a problem on their hands.
Microservices equally are an approach, everyone needs to get the concept.
Car sense checks
If you drive, when you get in your car, you tend to turn the key and set off. It’s human.
Yet when you get in your car you may or may not have some sense checks.
- Firstly how much fuel do I have?
- Also are the tyres in good order?
- Is there water for the windscreen?
- Are the mirrors exactly where I need them?
- When is the next service due?
- Is my tax, insurance and NCT (National Car Test / MOT test) in date?
- What’s my blood / alcohol level?
I’m just doing a run down to the shops… it’ll be fine.
Programming sense checks
So even from the outset, there are considerations beyond the programmer to consider.
- Firstly which language to use?
- Next, adopting which coding style choices?
- Does the solution have reusability?
- Also is serial, parallel or hybrid the best approach?
- Which architectures / stacks / technology do we need to support?
- Levels of documentation?
- Finally which architecture approach are we going to use?
Depending on the business rules a lot of these capabilities and situations are unfortunately disregarded.
We’re too busy to worry about that now is often the battle cry which makes it far harder in the future to retrospectively fix issues.
Considering check eight is what effect microservices will have.
Serial and Parallel
This is one of the hardest decisions for programmers as both approaches work but have very different challenges.
Serial. Everything executes in order delivered by one person. People in a queue waiting for a window in a post office.
You will get to the next one when the previous one has been fully dealt with.
Yet like people in a queue you run the risk of delaying things.
Please go to window 2
If you open a second or third window to process your queue, you are now processing in parallel. Instant win for speed.
Consequently however there is a massive challenge.
If being able to help the person in queue 3 is dependent on information or output from a person currently in queue 1, how do you handle that?
So parallel has timing and queuing challenges that serial doesn’t have.
Parallel has speed advantages but organisational challenges.
Behind the scenes
As the speed of one processor hits it’s physical limits the solution was parallel capability and that’s why the CPU today has multiple cores.
The operating system hides from the programmer how those multiple cores operate.
Using symmetric multiprocessing you can have parallel processors available but the programmer can simply write their program in serial.
Microservices consider multiple windows being open, so we have parallel issues to consider.
Everything in computing breaks down to input, process, output, the IPO model.
Give something to a program, it’ll do something and then output a result.
Programming represents piping through the | symbol.
Pipes enable one program to pass its output to another program.
Linking programs using piping is a serial approach.
When program 1 is finished all the output is piped to program 2.
So from the outset we realise that having a single serial interface (walking into one post office). Easy for everyone to understand.
How the process works inside the post office doesn’t matter to the customer, so long as its handled quickly.
We recognise that parallel has speed advantages over serial approaches yet we have queuing and sequential timing challenges.
Finally we get to microservices.
The user is only every going to interact with the interface. The programmer chooses the implementation approach.
In microservices each process could be written in different languages, using different approaches.
When something needs to update, you can update one process in isolation without a complete rebuild of the entire core application.
Implementing this approach is a choice! The programmers choice.
Each process can have their own unique approach, style and implementations.
So long as it can work with the interface, then no one but the programmer cares how it was done.
There is no hiding from the challenges but the benefits are noticeable. So discussion and team collaboration are essential.
Because the processes are independent entities you do have timing challenges.
If your programmers don’t use the same style, or even the same programming language, documentation and company style guides will be so important.
Piping introduces the possibilities of the message or the service not being available so there is more communication management.
Making processes capable of inter-operating is the key to reusability
By abstracting processes such as the send email approach above.
If the second process needs to “Send email” then instead of having to develop its own version it can just use “Send Email” as process 1 does.
Also if “Send Email” is enhanced then all that improvement is shared amongst all the processes.
This cycle of continual improvement builds a framework.
APIs or Application Programming Interfaces allow solutions to interconnect.
Converting to making the most of the approach, reusability and APIs is not difficult. It’s a programmers choice.
Shared libraries and APIs are two different ways to achieve the same goal.
Over time you can farm out your core application service calls to libraries or APIs.
As an example, decide today you’ll put the email sending outside your core application and congratulations your transition has started.