How Microservices Are Changing The Way You Build And Run Apps

Parsing out the hype from the useful information can be tough in technology. So, in this article, I’m going to try to sanitise the scuttlebutt and take a simple look at exactly how microservices are changing our industry, and why you should care.

If microservices are the answer, what’s the question?

The traditional way of developing software was to build a ‘monolithic architecture’. Basically one giant Jenga tower of code that ran all your products and services. The application was developed, tested, packaged and deployed as a single unit. That means that even for smallest incremental change the full monolithic application needed to be recompiled, relinked, and tested. In a world of fast iterations, agile development and massive scale – this can become a real challenge.

Image 1

Microservices are what happens when you decouple that monolith down into discrete services. That Jenga tower of code goes from being a single tower of 200 blocks, to 20 towers of ten blocks. You can imagine that makes it much simpler to switch out blocks for new services and features.

Take a shopping cart for an online store as an example. When displaying a product page, the mobile application would have to interact with four different services: User Account, Product Catalog, Inventory and Shopping Cart. In a monolith, (image 1)  all four services would reside in the same  code base. Any simple change to, say, the product catalog also touches the user account, inventory and shopping cart.

In a microservice architecture, User Account, Product Catalog, Inventory, and Shopping Cart functions are decoupled into separate, self-contained services (image 2) and then those services are further divided into microservices. The intent is that each microservice is small enough that a single developer is able to understand its entire code base. That makes improving and updating each service a manageable task which can help reduce development times, improve user experience, increase functionality and make application evolution far more sustainable.

Image 2

Sustainability, it seems an odd word to use. But we’re not talking environmental sustainability. Rather we’re looking at the potential for your application to change and iterate to keep pace with customers’ demands. For German retailer Otto, an early adopter of microservices, this was the most important factor in moving away from monoliths. In a blog last year, Otto’s executive software-architect Guido Steinacker explained it like this:

“Most of us forget that today’s most up-to-date systems will be tomorrow’s legacy applications. The stuff that you or people after you will swear about. Software that might prevent your company to survive future challenges.”

Otto’s team now believes that, thanks to moving to microservices, they will never again have to reimplement the company’s main online resource: otto.de. They might have to replace every single bit of the current software in the next decade, but it will be done slice by slice and it will not put the company’s revenue at risk.

You may be surprised to hear that HM Revenue & Customs, the UK’s tax body, is also another avid adopter of microservices. Recently HMRC announced that its Multi-channel Digital Tax Platform (MDTP) had helped launch 28 new services and save more than £8m in operating costs. Built on microservices, MDTP, has empowered a shift towards agile development that has allowed HMRC to go from two releases per year to 50 per week. The old metaphor of features missing the annual release train can be retired now that we have fleets of messenger bikes instead.

There are numerous other microservices examples too. From giant US retailers like Gap Inc, who use microservices to improve their supply chain functions, to entertainment start-ups such as FuboTV who have built a continuous integration and delivery pipeline that gets applications to market  faster with a lower cost.

Seems like a good idea, why wasn’t it always this way?

In the past, the potential benefits of a microservice architecture did not outweigh the difficulties of deploying and managing thousands of services. This was, to use developer language, a non-trivial problem (translation: “it was too hard”).

However, half a dozen years ago non-relational databases started to grow in popularity, including the likes of Cassandra and MongoDB (my employer). These databases offer a far more flexible data model to accommodate rapid schema changes, while seamlessly managing multi-structured data, and the ability to scale out on cloud based computing power. This gave developers the underlying agility needed to create and update multiple services.

Fast forward a few years and we get another introduction which pushed microservices mainstream: containers. Led by Docker, these containers allow developers to package up the code, along with all its dependencies, and treat that as single package. In a world where you have dozens or hundreds of blocks of code powering an application, containers make building, packaging, testing and deploying much simpler. Now orchestration frameworks (like Kubernetes and Mesos) are making it possible to do that at scale.

The microservices trend is a product of two main factors: the business need for delivering better stuff to your customers quickly and the introduction of lightweight easy to use technology. However, it’s also important to point out that microservices are not a magic bullet. It is a big organisational and technological change for a company and microservices are not right for every situation. Before starting out it’s vital you have the right staff with relevant expertise.

But as the likes of Otto and HMRC are demonstrating, with the right people in place microservices can help transform your organisation. So, if the time is right, go ahead and tear down that monolithic Jenga tower.