?This article first appeared in Information Week.
In the ever-changing tech industry, companies know they have to ride some swift rapids to stay afloat. In fact, agility is perhaps one of the most important keys to business success – because if a company takes too long to react to change, a new innovative startup will most definitely swoop in to take their market share.
While microservices isn’t the most recent buzzword to hit software development, it’s received a lot of attention lately as a viable option for companies wanting to evolve their capacities and stay on the cutting edge. Microservices is a development architecture that deploys applications as modular services, which then run different processes and communicate through flexible protocols. It allows for swifter updates and rapid, complex expansion. And it’s exactly what companies need when they scale and put new business processes into action.
Sounds useful, right? It is. But before leaping headfirst into microservices, you need to make sure your company is prepared for the challenge. Here’s what to consider before implementing the architecture, and how to make the most of it if you do:
Look closely at your business structure
Are you large enough for your development teams to work separately on complex projects? If not, you probably don’t need microservices. According to Chief Scientist at ThoughtWorks Martin Fowler, the productivity cost of microservices is only worth undertaking for large and complex software projects.
“Unless you’re faced with that complexity, remember that the microservices approach brings a high premium, one that can slow down your development considerably. So if you can keep your system simple enough to avoid the need for microservices: do so,” he says. All in all, companies with small development teams and a traditional monolithic application likely work more efficiently without microservices, and certainly don’t warrant a switch to the architecture.
Determine if you need to deploy components independently
If you constantly have at least two domains in the software you deploy – that represent completely separate business capabilities or processes – you have good reason to adopt microservices. Doing so will enable you to create an independent development lifecycle for various components of your application, which allows them to be updated or deployed without affecting other components of your application. Additionally, you can code the domains using the language that makes the most sense for that component. However bear in mind that these situations require more single component pieces to be dynamically managed by specialized development teams – so you need to make sure you have enough talent on staff or have the budget to afford them.
Consider if your team has the right skill set
A microservices architecture means you can create smaller development teams that specialize in certain areas of expertise. This should increase the ability to constantly release new functionalities to market, giving you an innovative edge and a competitive advantage.
However, before making the switch to microservices, think about how experienced your players are. Is your team mature enough to work with Continuous Deployment and Continuous Integration? Are they well-versed in DevOps culture? If your team doesn’t currently exhibit these skillsets, work on building a more robust group of engineers in order to deploy microservices efficiently. Or, find external partners who can help to complement your team.
Be realistic about your business’s roadmap
The ability to exponentially scale has made some of the largest companies into what they are today – think Airbnb for example, which grew from an air mattress rental website to a $30 billion data-driven marketplace in less than a decade.
While it’s important that growing companies remain agile, not every organization has a big need to scale. If you honestly don’t need to address complexity yet, don’t push yourself to adopt a microservices architecture in order to rapidly scale.
Be realistic about where your business is headed – at least for the short term – and don’t make your development process more complicated than it needs to be.
[TRENDING: Outsource vs Offshore Part 1]
So, you’re 100% certain microservices is for you. Here are some quick tips:
- Once you implement a microservices architecture, be sure to make extensive use of Domain Driven Design, especially the concept of Bounded Contexts – these are clear boundaries that separate a domain, or the subdomain it uses and clearly define the interrelationships between the participating contexts. This gives teams a clear understanding of what has to be consistent or can be developed separately.
- There is no golden rule about how to define Bounded Contexts, as this depends on the domain you’re working on. Although a context map – which shows where each Bounded Context is in relation to others and how they communicate and share data – is a good technique in general.
- Many experts propose using small microservices. But the size should really depend on how cohesive the concepts are within the domain model, within their Bounded Contexts and the ubiquitous language used. Actually, Lightbend founder Jonas Bonér believes a single-entity microservice is dangerous, as it risks making the scope so granular that it stops representing the domain. Essentially, each microservice should represent a business capacity and focus on completing that component well, independent of other services.
- Make sure you align your development team structure to the Bounded Contexts you have defined. As you all already know, Melvin Conway said, “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” To reap the benefits of a microservice architecture, your teams should be built around business capabilities. You should not develop transversal teams that create new silos and reduce the independence of your delivery teams.
While it’s definitely tempting to quickly jump on board with ‘hot’ software trends, leaping into microservices head first may not be the wisest move for every company. Every business is different – whether it be in size or skillset – and each needs to find the unique solutions that work best for them. Through keeping in mind your business structure, determining if you need to deploy components independently, analyzing your team’s skill set, and being realistic about your business trajectory, you’ll be able to determine if microservices are right for you – or whether it will only make your processes more complicated.
