Many small and medium-sized companies have adopted a microservice architecture. The adaptability, scalability, and agility that the microservice patterns unlock are very appealing to these companies. These attributes are also appealing to larger companies too. But other attributes also tend to temper some of these benefits.
Adaptability
Polyglot is the name of the game. Teams have power to adapt to the best solutions to the problems they face. That may mean choosing a particular programming language. That may even mean adopting an alternate delivery pipeline. What about choosing tools like bug trackers?
Large, enterprise corporations tend to limit adaptability. They are not exactly known for flexibility. These organizations have strict security requirements that may limit the number of choices for languages and delivery pipelines. They have strict release gates that may be hard to replicate, so teams are limited to fitting into the centralized delivery pipeline. The new versions of Java may not be supported by the corporate security scanning tool. They are paying lots of good money for this CRM or bug tracking tool, so you better use it.
Of course, not all of this is bad. Even when given a wide array of choices, less constricted teams may choose to centralize many of the same items. That just makes sense; it allows the teams to actually focus on producing differentiated software, rather than spending time working on setting up a delivery pipeline. Sometimes developers want to feel like they have the choice, even if they do not ever take it.
Scalability
Obviously the ability to scale on demand to the current load of a system would be a good thing. Production going down because of too much load is a very visible failure. Paying too much for hardware that sits idle can kill a business. Having the ability to scale up to meet demand, and then scale back down to not waste resources is a great middle-ground.
Does this ability to dynamically scale actually help you? This pattern is usually only really useful in a cloud context, where you pay per hour, minute, or second that your “thing” is running. In that case of course you want to maintain as minimal a footprint as you possibly can. However, many of the enterprise corporations are averse to living in the cloud. They have many reasons for maintaining their own hardware in their own datacenter.
In these cases, when you have to buy the hardware to handle maximum load anyway, it may not make sense to maintain a minimal footprint. The effort to dynamically scale up and scale down may just be wasted effort. An instance where this may still be useful is if the nature of your business means that various systems are active at different times. Here, it may still be useful to develop dynamic scaling, even with fixed hardware.
Data
One of the patterns that helps to keep microservices independent and unlocks the ability for services to rapidly adapt is that each service owns its own data. This way the data for the service can change as the service needs. No coordination with external services around that data is needed. The downside of this, is that data ends up being duplicated a lot. Services should be independent, so they cannot rely on other services. So if you need to include a user name in your response, and you are not in the user/person context, you will need to duplicate that data.
None of us are perfect, and neither is the code we write, so issues naturally arise, where the data is not consistent. A person’s name may not consistently update across services. A budget may not reflect that it was deprecated in a recent transaction. We get away with this by saying it will “eventually be consistent”. The system will always be working towards a consistent state (but may never actually reach that state).
This type of consistency model may not fit some enterprises. Banks may not find this acceptable, so they will need to make tradeoffs, sacrificing some availability and agility for consistency. There are other sacrifices and patterns that may be applied to help alleviate this tension too.
Considerations
There is no silver bullet. The patterns and architectures that fit for one business may not fit in another business. In different contexts different problems arise. Different constraints are imposed. When trying to find the right patterns and architectures, we must take these problems and constraints into consideration. Just saying we will use a microservices architecture will not solve any problems.