How Microservices Can Help Your Teams Be More Agile
Microservices are relatively new to most organisations and many wonder how adopting a microservices architecture will impact their teams. In this article, we’ll discuss how adopting microservices can improve the agility of your development team.
What are Microservices?
Microservices consists of a suite of small services that are independently deployable. A microservice also runs independently, without the need of any other part of the system. Usually each instance of a microservice will have its own database and is often stateless (does not require the server to retain session information).
The opposite of microservices is the monolith, which is always built as a single large unit.
If a developer has to make a change to a monolith, the entirety of the monolith must be built and deployed. However, with a microservice, only the small unit that is affected has to be built and deployed, which is much faster and safer.
Autonomous Teams and Local Decision-Making
One of the key values of Lean and Agile are to enable teams to be autonomous and to allow them to make decisions locally, rather than be directed in the style of “command and control” or indeed for teams to continuously be dependent on other teams.
By splitting a system into multiple small microservices, it becomes possible to organise cross-functional teams for each domain-context or feature set. The teams can then have a demarked area of code that they “own” and can therefore make local decisions for that microservice.
In order to get teams working more efficiently, it is important to ensure teams are not dependent on anyone outside of the team to deliver features. In a monolith application, it is much more difficult to enable local decision making, especially if there are multiple teams working on the same area of code.
Emergent Design
One of the 12 principles of Agile mentions that “the best architectures, requirements, and designs emerge from self-organizing teams.”
A popular practice within XP (Extreme Programming) is to ensure designs are as simple as possible. TDD and BDD encourage teams to only create designs and code that meet the minimum stated requirements, discouraging the bad habit of over-engineering. Over time, simple designs can be expanded upon and the original design evolves into a different and more appropriate design as the service is enhanced.
In order for designs to emerge, teams must be allowed the autonomy to self-organise. As discussed above, adopting a microservices architecture enables an organisation to map a microservice to a small team. By allowing these teams to be autonomous you are also encouraging the best designs to emerge.
Short Iterations and Continuous Deployment
Short development iterations and continuous deployment are core principles of Agile.
By limiting a Sprint to a fortnight, teams are encouraged to deliver the most valuable set of features into production at a rapid pace. The DevOps concept of Continuous Deployment assists this short iteration of delivery by enabling multiple small releases to be deployed to live environments on a very frequent basis.
Microservices are (by definition) small services, which makes it much easier for teams to create, learn and adapt these services within a short development cycle and to also deploy these to the live environments using continuous delivery.
Trying to do the same with a monolithic application is far more difficult as a larger application takes much longer to build and deploy into the various environments and over time, the cadence of delivery is substantially impacted.
Adaptation
Microservice architectures promote another pillar of the Agile manifesto: adaptation (responding to change).
Both technology and the market move at a rapid pace these days. In order to keep up, we need to regularly adapt our applications to the market needs or to new technology stacks.
However, monolithic applications usually embrace one technology stack for their entire lifecycle, making the application highly coupled to the technology and difficult to maintain over the longer term. The bigger the system, the bigger the chances are that something will go wrong during the infrequent release process, despite all the automated scripts written by the SysOps.
With microservices, we develop API-driven applications and we really don’t care what technology our service is built with. We can choose different technologies for each service, depending how the technology fits for the purpose of the service.
This makes us even more agile as we can adapt easily to the technology and market changes. For example, we don’t have to rewrite an entire system when a programming language becomes obsolete; instead, we can simply keep the existing code as it is and create the new services using the most appropriate new technology.
This aids the speed to market and hence generates faster returns in an ever-changing market.
In addition, microservices give us great flexibility in terms of deployment, versioning, AB testing and experimentation. We can experiment with a new feature by only making it visible to a segment of the customer base and we can kill features whenever we need to. We can easily deploy a new feature without having to redeploy the entire system and this lets us respond quickly to market demands.
Conclusion
Microservices are a perfect fit with Lean and Agile. Adopting microservices enables development teams to further enhance their agility and deliver in the most efficient way possible.
