Microservices Architectures Are Here to Stay

Like many with me, I have considered microservices architectures just for a select few forerunners, like Netflix, PayPal, Uber, Twitter, Airbnb, Lyft, and Spotify, but recently I’ve realized that this is a path that most organizations will have to take sooner or later on their digital transformation journey. In the animated image you can see how Netflix is monitoring their 500 services or so in real-time, and each white dot is a request. On the left is the load balancer and on the right are the databases, and the most crowded paths of requests in the middle are their APIs.

When a new approach to building digital solutions comes along, the instant impression that you have to start over is usually not true. When mobile apps came along, a lot of what we already knew was valid, and the new stuff was mostly on the client side, with new operating systems and programming languages to learn. With the Internet of Things, apart from the hardware and the embedded code, even some parts on the server side changed, with new protocols and ways to handle large amounts of real-time data. But when it comes to building systems with microservices architectures, it’s actually a drastic change on many levels, and not only related to technology.

But to start with the technology of microservices, the smallest change is to split up old monolithic code into smaller services, and with an already well-designed (e.g. SOA) architecture, that’s actually not very hard. What gets hard is to load balance, fail-over, and auto-scale these services on a sub-machine container level, which in turn require new approaches to dynamic service discovery, versioning, and various security aspects, like authentication. When you got all that figured out, you realize that the remaining obstacle to infinite scalability is the inherently monolithic relational database. Despite its fantastic ability to adapt to any new requirements with a new (join) query, in many cases it simply has to go away (and yes, as an old-timer, I’ve been struggling a lot with this one). Each service has to own its data, and the best way to make sure that every service is up-to-date with what it needs to know and/or affect, is to have them tap into a central data streaming pipeline with everything that is happening. To be more specific, on the Microsoft platform I’m talking about Azure Service Fabric, DocumentDB, and Event Hub in Azure, with IBM it’s mostly about Containers, Cloudant, and MQLight in BlueMix, and some open source alternatives are Docker/Swarm, DynamoDB, and Apache Kafka. An interesting detail is that languages are actually of less importance, and it’s mostly easy to mix them, but this diversity can make it harder to share/reuse and can create a fragmented culture. For those that want to go deeper, I recommend the free book Microservice Architecture.

Beyond tech, and probably most important, is what has to change in the way people work. The old large silos of business/sales, marketing/design, development, test, operations has to move into small autonomous teams with all these capabilities that can take something of value from idea to run in production with high speed and high quality.

Whether you have been thinking about this already, or this comes as news to you, I suggest you start experimenting with this approach, these technologies, and these new ways of working.