According to Gartner, microservices are part of the top 10 strategic technology trends for 2017, in support of mesh app and service architecture. You may have heard of microservices, but have you considered how they could benefit your applications and organisation in a Hybrid IT environment?
Microservices are independent application components that deliver specific outcomes and processes.
These components can be combined together to create a higher-level outcome, or complete application.
By their very nature, microservices are loosely coupled and can be interacted and combined via predefined Application Programming Interfaces (APIs).
This componentised architecture is well suited to cloud platform services. While it’s not mandatory, they work well together.
The elasticity of cloud platform services means they are excellent for scaling to meet demand.
Microservices can be scaled independently and therefore you do not need to scale your entire application. Instead, you can maintain performance and right-size infrastructure to meet the application component’s needs.
The alternative approach is to create a monolithic application architecture. Although this may be made up of a number of modules, they are often so tightly coupled, they must be developed, deployed, managed, upgraded and scaled as a whole.
The fact the application must be treated as a single entity and cannot be separated is a huge limiting factor, and one that is the key benefit of microservices. All other benefits can be linked from this single fact…microservices are loosely coupled and have well defined dependencies between each other.
A real life microservices example
Right now, I’m the business owner of a new application development project. This application is being developed with a microservices architecture, connected with RESTful APIs, on a fully containerised infrastructure which is being orchestrated with Kubernetes.
Yes, I know…I probably could not have crammed many more buzzwords into that sentence even if tried. Well, I could have added blockchain or serverless, but that is not the point. What I’m saying is, that this approach is providing me with tangible benefits.
Most of these benefits can be ratified down to a single unifying feature of microservices:
Microservices are loosely coupled with well-defined dependencies between each other
Let me explain, what impact this is having…
Geographically dispersed development
Defined dependencies help to make my geographically dispersed development team productive.
The team is working in different locations around Fujitsu’s global organisation that has been mandated due to skills and other organisational characteristics. This is common in many large enterprises.
The benefits of collocated teams have been well documented. However, I’ve been able to limit the impact of this geographically dispersed team by enabling each location, team or sub-team to be productive.
This is by focusing on a specific set of microservices to avoid conflicts and to limit the challenges of communication across time zones.
Multiple development languages
Again, the defined dependency nature of microservices has given the team the freedom to use different development languages.
They are able to select the best technology to suit the specific needs of each microservice. Because each interact only by RESTful APIs, they are able to communicate with no issues.
Using a specific example, some authentication and authorisation features have taken advantage of Go, while other services use Python.
This must be balanced with the long-term supportability. However, as this application is following a DevOps model, I have less challenges in training a support team in all of these technologies. Instead, the development team are responsible for the support themselves.
The simplicity of each microservice makes the development on boarding time faster. We’re able to on board a new developer and focus them on a subset of the application, by having isolated components with well-defined dependencies into other services.
This has enabled them to become productive within a small bubble, without having to understand the entire puzzle. Here are three other benefits to consider:
Now this is a microservices benefit, but it is also a benefit of the containerised infrastructure on which they reside.
If the application is hit with a demand spike for a specific function, I can scale out that specific microservice without having to do the same for the rest of the application. This is due to the fact functions of microservices are independent.
You could argue that this a key benefit in itself, but it is only possible due to the defined dependencies of microservices.
This is a benefit derived from the low dependencies, and means a failure in one microservice might not necessarily impact another. Therefore, errors might limit the use of certain features, but are much less likely to bring down the entire application.
This is facilitated by loosely coupled dependencies in the application. I can push new updates to single microservices to add, remove, or enhance features very quickly. The impact to other services is very low, or at least well known!
This helps the development team to operate within a continuous integration and continuous deployment (CICD) pipeline, reducing the time that my customers need to spend waiting for new features.
It sounds simple, right? One key feature has completely changed the way that we are able to create new applications and with the rise of both cloud platform services, the growth of microservice-based applications will definitely grow.
It would be wrong for me to simply focus on the benefits of microservices, without reference to the challenges that this architecture brings.
Trying to transform a monolithic application into microservices, or building one from scratch in the first place is a huge challenge. This is especially true when you consider the lack of skills and experience of doing this at an enterprise scale.
On top of this, once you have completed the initial build, issues such as monitoring all components, root cause analysis and the general increased system complexity are all present. This requires very careful consideration and management.
We don’t have enough time to explore these challenges in depth, but maybe it will be the subject of another article on the Hybrid Hive in the future.
I’d love to hear your views on this, any challenges that you may have faced. And if you can spot a benefit of microservices, which is not directly associated to the loosely coupled and well defined dependency nature of microservices, bring on the debate!
Footnote: a big thank you to Fujitsu Lead Orchestration Architect, Hybrid IT, Janne Laitinen, for assisting in creating this article and making sure I didn’t drift too far from the facts!