A few weeks ago I gave a talk about microservices and how, now they have become a very widely used architecture. I stated that when building microservices people often stumble across common issues that can be addressed through certain well-known solutions. The talk featured a hands-on demo of how easily you could set up your environment when using the right tools. One such tools is JHipster.
Microservices are no longer a hot trend, mainly businesses having implemented this architecture with some degree of success. In the beginning microservices seemed like that one-size-fits-all solution for all problems. It promised scalabilty, zero downtime deployment and many more. These can be, however achieived only when doing it right. Many organizations claim to do microservices, however they only do a glorified SOA. Which brings me to my first point of the presentation. How did we get to microservices and is there anything beyond it?
In the early days of software developement all functionality was developed as a single deployable and scalable block. This is called the monolith. This is actually the most intuitive way of writting software and it still works well for small to medium one team projects. Over time, the codebase grows and becomes difficult to maintain. The build artefact is typically deployed to a static infrastructure - think your clustered application server such as Weblogc, WebSphere, Glassfish. A single database type ensures as persistance needs.
As applications started performing more business operations the monolith eventually got split into multiple component that comunicate of the network. This architectural style is refered to as Service-Oriented Architecture or SOA for short. Functionality is split based on business logic, communication between them is done over the network thorugh an enterprise service bus (ESB) or web services (SOAP and later REST). The infrastructure continues to be static and the datastore is common to all components.
The next evolutionary step to architectural styles is then microservices. It takes the good parts of service orientated architecture and brings a bit more flexibility to deployment and scalability, backed up by the increased popularity of the DevOps culture. A typical microservice application is a highly distributed system made of single reponsability components that can be deployed and scaled individually. Additionally they can levarage different persistance technologies. However splitting the functionality into mutliple modules is not all what it is about. Ensuring the applications are designed and built in such a way that they can scale easily is a must.
The architecture in itself is no longer something new. There are already companies that have been successfully running them at scale. Experience has shown that the solutions to solving issues on a certain project can be re-used to anticipate the same on another one.
Here are those that I have identified:
- API Aggregation - as microservices are highly distributed system you need a central point of entry that someone can use to consume your APIs. This translates to using an API Gateway.
- Service discovery - given the dynamic environment microservices run in, they require a kind of mechanism that will help identify instances as they come up and de-register those that are no longer running.
- Centralized configuration and logging - a distributed system requires a central point of control, which is achieved through configuration and observability.
- CI/CD - scaling microservices will not be possible without the use of automation in your build and deployment processes. Building automated pipelines is a recommended practice even when not building microservices.
- Authentication & authorization - be it fine-grained or coarse controlling access to your API is cruicial.
- Versionning - everybody is using - hopefully - using some kind of versionning systems for their code. Extending this idea further to configuration, databases and API’s will help you lower the number of regressions and also keep track of the changes occuring in your system.
- Testing - while many developers don’t like it, integration and unit tests are like a contract that ensures to some degree that functionality is stable
- Infrastructure - gone are the days where servers where created manually, by a team sys-admins that were the gate keepers of the root passwords and IP address of the servers with more RAM. Now infrastructure acts as a digital playground where businesses are able to experiment and find out what is the solution will help them optimize their time to market.
- Documentation - again, nobody likes it and to some extend you should do too much of, however having a README file that will help you get started with your project might save you time especially when on boarding losts of new people. How about Swagger for describing your API?
Given all of these wouldn’t it be nice to have a tool that would help you get started will all of these?
See the video below.