DEVOPSdigest

Microservices have changed software development and promise powerful benefits. Instead of traditional monolithic architectures, individual teams create small pieces of functionality, which are then added up to be the whole. These smaller pieces are easier to replace, and years have not been dedicated to creating a particular microservice and being locked into one platform.

Also, it is theoretically easier to be innovative and responsive, and to scale up to meet additional user load or demand, compared to a monolithic app, where the entire architecture essentially has to be cloned (another copy of the database, the web server and the app server).

Microservices fit in well with open source, largely because microservices depend on container orchestration tools, which happen to be open source, and many related tools — such as service meshes — are predominantly open source packages.

The Pros and Cons

For some organizations, microservices enable the agility that modern software development needs. However, it is a big step: some organizations have already struggled with Agile and DevOps adoption: microservices are an even bigger challenge. Gartner has previously predicted that the majority of organizations will find microservices too disruptive and will look at alternatives.

To give this some context, here is an example. Imagine an ecommerce app for online checkout, involving pricing, a shipping calculator, and an inventory all working together. Then imagine it is Thanksgiving, and the website is being overwhelmed by enquiries from a particular zip code. With microservices, it is relatively simple to spin up a new instance to handle the extra load, compared to a monolith, which would require another instance of the entire app.

However, the amount of effort to coordinate all of the moving parts can increase dramatically. To work in harmony, microservices need continual monitoring and a view of the bigger picture. While they are loosely coupled, in fact microservices may depend on a couple of others to perform well. So, if a version changes, there must be a way to notify related microservices teams, but without creating a lock-step situation. Service meshes can help make systems more resilient, but even so, microservices can easily lead to uncontrollable chaos if not planned appropriately.

Alternatives to Microservices

An alternative approach is macroservices, using chunks of previously-proven parts of the monolith, but bring legacy problems. These include code that is hard to read, or it may be difficult to get a workable public API, and testing and scaling-up may be challenging.

Another option is to use miniservices, where two or three share the same database, unlike microservices which each have their own data storage. Miniservices are independent but coordinated. There is the downside risk of "miniservices creep," caused by teams adding more shared data stores, APIs, and other features. This can lead to a bloated environment, so miniservices need a lot of control from team leaders.

Playing devil's advocate, is a wholesale move away from monoliths always necessary? If new releases are rare, a monolith may be fine for the moment. Agile and DevOps, with some help from REST APIs, can improve efficiency. However, it is likely that for any organization, at some point, a more flexible way of working will become imperative.

Team Culture is Everything

The bottom line is that there is no one-size-fits-all approach to modern software architectures; each have their pros and cons. Furthermore, the importance of the cultural approach outweighs the choice of architecture. Failure might be blamed on microservices, whereas it could have worked with the right team culture. Sure, tools like API management, version control, and automated testing help, but they are not the answer on their own.

An incremental move away from monoliths is another option, perhaps just transitioning the parts of an app that change most often, which will also give the organization some experience of what does — or doesn't — work, before making a bigger commitment to another approach.

New ways of developing software have huge potential for flexibility, innovation, and time-to-market, but regardless of which structure is chosen, the impact on the culture cannot be under-estimated.