The Microservices Movement
9th April 2020
Microservice based architecture is now way out in front over monolithic counterparts for many enterprises producing next gen products today…and for good reason.
In this one we explore the microservices movement and why microservices are so powerful.
What are Microservices?
Microservices form an architectural design implementation, most noted for its split of individual components as a collection of services that are linked together to form an application.
Each service has a clearly defined purpose and is completely self contained.
A small example of this is a service handling data-ingestion which contains an endpoint that accepts data into an application. A database containing the initial data ingested and then a message queue, holding any transformed data ready for the next service to pick up.
Each microservice can be deployed and tested independently, all via automated means using a continuous integration and delivery pipeline.
Benefits of Microservices Architecture
Each service is totally separate to the rest of the application and therefore can be developed, tested and maintained separately, to the rest of the stack.
Applications can be scaled far easier than monolithic counterparts.
By focusing only on the individual components needed to scale at any one time, performance testers can help businesses show where bottlenecks are in specific parts of their system and enable dev teams to scale up individual services as and when necessary.
Again due to the split of each service, a large dev team of multiple scrum teams can work independently on individual services in each sprint. Where a service does integrate with others, contracts between each service further the independent nature of microservice development practices.
This often removes the problem of inter-team dependencies and often results in faster development and higher levels of productivity. Of course sometimes there is overlap, but it’s much easier to avoid!
One major business benefit of microservice based architectures is actually from a staffing perspective with the simplification of shifting an applications tech stack.
For example, some engineering teams consist purely of. NET developers, some of Java, some of NodeJs, Typescript or Python. Some also adopt the form of a mix mash of multiple languages.
But that’s all good, because microservice based architectures allow organisations to swap out or trial programming languages and technologies, whenever necessary. Technically, each service could be developed in a different language!
So consider a corporate restructure, relocation or even just testing out the adoption of a new language in your company.
This benefit opens up a huge pool of employees, as it essentially gives companies adopting this architectural style, access to the whole development market rather than a specific segment.
As you can imagine this is quite powerful for business owners and thus enables organisations to evolve their product, tech stack and staff members in a way that has been traditionally difficult in the past.
The traditional focus on the product with most application development projects is that on completion of the project or even a given sprint, the software is handed over to customers and the support team takes on customer communication and any issues that may arise.
Microservice based products however, can avoid this project handover and support mentality, or at least as much as possible.
Instead in many teams adopting this style, the team who builds a particular area, owns that particular area. This brings developers into close contact with the bigger picture, being the live product, customer pain points and day to day production usages of their software.
With user analysis tools such as Mouseflow and event logging systems such as Kibana, the developer owns and understands more of the self contained area than any support team. Directly linking this all in with a product owner…it allows for rapid improvements of a feature as time goes on.
This sort of product mentality, also links directly to business goals and capabilities. Rather than looking at the software as a set of functionality to be completed, there is an on-going relationship with the customer, where the question is how can our software assist our users to solve their problems?
As a by product of solving customer issues in this fashion, it ultimately enhances the businesses offering, capability and user experience.
6. Teardown and Evolution
The customer and product mindset also ties in with microservice tear down and evolution. Where if a customer need requires 2 services to be de-commissioned and 3 put its in place for x y and z features. This can be dealt with by the delivery team, in a fast, functional and scalable manner.
The result of all this is that time to delivery reduces and the product and engineering teams, get to attack the market faster and ship the solutions customers want, as often as possible.
To round off, a caveat here, microservice based development can be tricky in practice to get your head around at first, but once you get to grips with it you’ll see it is an efficient way to develop software.
A choice toward microservices based development, can result in features being built, tested and deployed quickly. Enabling product and engineering teams to achieve business goals and produce highly scalable products that customers want and solve their day to day problems.