|
Ever been involved in a software system that has gotten hard to maintain and develop over time? No sh*** Sherlock, you might say, who hasn’t? I believe most developers have experienced this, and that the issue is somewhat inherent in working the life cycle of a software system which spans a longer period of time, and employs a certain number of people. OK, that isn’t very tangible - I know - and I don’t have any scientific data to back it up, except for heuristics derived from personal experience and other narratives.
Size matters I stumbled upon this article by Michael Feathers, that seems to point in the same general direction. I think it is safe to say that complexity is bound to increase with the size of the system. As you introduce more functionality into a software system, which for example is built around a monolithic architecture, you will eventually find yourself in a state where changes to one part of the system might affect another part of the system, even when it “should not”. This impairs developer productivity. Many narratives also speak to the fact that when introducing new team members it takes increasingly long time before they are productive. Microservice architectures While not a new concept at the core, Microservices is a development of the idea of component based software system that has a very promising outlook to address just these (and some other) issues. The exact definition of a Microservice architecture is not carved in stone (it may be a little early for that still), but there are a few resources out there trying to describe what it is, for example this article on the Martin Fowler blog, which states: "In short, the microservice architectural style[1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API" As explained in this Computer Weekly article, the developments we have seen over the past few years where HTTP and XML/JSON have become de-facto standards for interprocess communication across platforms - architectures that are components in both source code and runtime are much more accessible in reality now than when the industry was struggling with compatibility issues inherent in protocols such as RMI, IIOB and RPC. Architecture requirements need to be broken down Back in the days when I was a consultant, a requirement specification from a client sometimes would contain a variety of the somewhat naïve statement that “It should be easy to add functionality to the system over time”. The scope would typically be a custom built software system. As a consultant, how do you deal with a statement like that? It is hard to test, and when the time comes to actually add features to the system, you are probably gone. Working for a product company, however, the requirements on the architecture becomes extremely important because (soon enough) the choice of architecture will govern (as in restrict or enable) everyday work for pretty much everyone in the company from developers, through sales reps to senior executives. In what follows, I will try to break down what the simplistic statement would (should?) entail in many cases. Chances are, if your ambition contains elements listed below, a Microservice architecture is for you. To the point, 4 main drivers for a microservice architecture So, how do you end up choosing a Microservice architecture for your product? There are a number of articles out there focusing on the technical benefits to a Microservice architecture. I intend to talk about some aspects related to business risk, scale and team composition that in my experience will drive your decision from a business point of view. It is indeed my opinion that the choice of architecture eventually defines your company’s ability to operate and innovate consistently over time. In my experience the following key requirements will eventually lead to the choice of a Microservice architecture, and it will secure the future of your organization. The ability to operate under risk and uncertainty If you’re in it for the long run and don’t have all requirements when you start your venture, you need to be flexible and agile (for lack of a less used term). Starting a new software product, be it a vital part of a product company or a support system for a certain business unit, has a risk and uncertainty component to it. As someone who is tasked with building the software, you are likely not to be equipped with a full and flawless understanding of the needs of your customer. You might be nodding in agreement, thinking that is where agile and lean comes in to play? You’re right of course! I do, however, want to add to the mix that in order to be agile for real, you need an architecture that supports being agile. If you do, you can accommodate risk mitigation more easily than if you’re struggling with a growing monolithic software system. The risk will probably take on different shapes as times passes (in the beginning, you might want to know that you’re in the right area at all, later you might “just” be adding features to a thriving product). By modularizing your architecture, you can counter play risk scenarios more efficiently, deploy new or updated features faster, and even remove features without the need for surgical precision operations to carve out code from your project. The ability to scale Scale is a multi-faceted term in this context. I don’t think I will upset anyone by claiming that most companies would be thrilled to run a business that is successful enough to require more servers to accommodate customer demand. If the system is monolithic, we are used to horizontal scale strategies; you add more servers as needed. When considering scale at a broader range, you may want to include other dimensions such as
Cater for innovation You want to test new things, add and remove functionality in a relatively easy manner, and thus keep up an innovation speed that beats competition. To do this in a manner that does not intrude on current customer base, and that allows you to test on a selected few is far easier if you embrace a Microservice architecture than if your are confined to a monolithic system. Team organization The impact of your organization on your success as a software development team has been discussed at length by others; not least in Conways’ law. If you are familiar with Fred Brooks’ The mythical Man-month, you may subscribe to the idea that adding more people to a team will cause overhead that costs more than what you win. At the same time, you want to add more features to your product to satisfy customer needs in a manner that keeps you ahead of competition. So, if you can create an architecture that allows you to keep teams small and (as much as possible) independent of each other, you’re on to something. At Amazon they coined the term Two-pizza teams, to define a full team as per the amount of pizza needed to feed the team members: When you need more than two pizzas to feed the team, add another team - and at the same time - add another (set of) services the new team can work on independently from existing teams. Should you start off with a Microservice architecture? I suppose you can argue both ways here. On one hand the Microservice architecture will give you many advantages. On the other it will also make your initial development effort somewhat more advanced; i.e. it will take longer for your team to deliver initial business value. There is a certain overhead involved in getting up and running, both in development, but also in operations - Microservice is not a free lunch, as Benjamin Wotton states in his article (don’t forget to read the comments, too!). Some people even think that you shouldstart out with a monolithic architecture and refactor later to a Microservice architecture. If I were to break it down to a simple model for decision making, I would say
How do you make it work? So, you have made a choice to go with a Microservice architecture, how do you go about making it work in real life? That is the topic of a later post. Comments? Yes please!If you have experience with Microservice architectures, or just a general interest, I would love to take part of your comments in the comments section. Do you think that other values should be taken into account than those included above when choosing a Microservice architecture? What are the drawbacks? Comments are closed.
|
