Microservices at the W-JAX – lessons in monolith destruction and hype deflation
Are the promises of microservice heaven true? Are they better than monoliths in every way? And does a distributed system save money? We report on the latest advice of various microservices experts speaking at the W-JAX 2015.
Developing fast, releasing fast, more flexibility, AB tests… there’s no shortage of hype around microservices. And for good reason, say many speakers at this year’s W-JAX in Munich. Microservices can help us build autonomous, cross-organisational teams; teams can deploy independently of each another. We can selectively build technologies that are catered towards specific problems. And we can design for replaceability.
But is it all as rose coloured as this in reality?
It seems all microservice experts have one thing in common. They like to make bold claims about the power of microservices, but then add a deflating caveat, warning about too much hype. “If you mention one more buzzword, we’re going to have words,” Markus Eisele says to his co-presenter Jan Wildeboer during their keynote on BizDevOps.
“Who uses Docker?” asks Eisele. Hands shoot up from the crowd of over 1,000 developers. “And who has managed to actually build something useful with it?” All but four or five hands disappear. The lesson here is, we need to do a reality check on the promises of all hyped technologies, especially microservices.
Do not switch to microservices to save money
“The start is where it hurts,” says one speaker Tobias Flohre. Don’t expect that massive increase in speed to appear overnight, he warns. And if budget is a problem for your team, microservices might not be the solution for you. In fact, you’d best steer clear of microservices altogether.
A dismantled monolith does not mean cutting costs. Especially in the beginning, when implementing a radically new approach, any obstacles you hit can be expensive. Never switch to microservices to save money, Flohre concludes.
Meanwhile, we should always make sure to plan ahead by thinking about how we want to integrate any ball-and-chain legacy systems, explains fellow speaker Dennis Schulte. Companies are often faced with the task of getting a new base of macro-architecture communicating synchronously with HTTP REST to work and communicate with an old, but still essential, legacy system.
Senior engineer Björn Stahl says his enterprise team was lucky enough to start with a ‘green field’, meaning they could build up a ‘pure’ microservice-based system. Usually it’s only startups that can enjoy this freedom, but the burden of legacy systems makes it worth it for all enterprises to consider if there’s a way to work without them.
You don’t need service discovery in monoliths
You can say what you want about the business agility of microservices, but monoliths have some advantages too. For starters, you always know where your components are. But when you break up the monolith into a distributed system, your individual components automatically lose their ability to track the individual ports and unique IP addresses of other components.
Some people might think the solution is to hard code the location, say Hendrik Still and Tobias Bayer. “Service A wants to call Service B, so we can hard code B’s IP in Service A.” But Still and Bayer explain that this isn’t the most dynamic way to let services communicate.
Instead, the two microservices experts recommend service registries as a solution to this problem. This means when one service wants to find another, it simply asks the registry, an address book of sorts, to look up any information it needs. The most popular of these tools is Netflix’s Eureka, a single purpose registry designed as a solution to this problem for distributed systems. Featuring a simple REST interface and a Java Client, this service registry (in the Netflix team’s words) “is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.”
Autonomy is great
As many will know by now, one team will own one microservice. And that’s a great thing, most speakers agree. This means that one team can have full control over technology and architectural decisions, as well as data maintenance. There’s also no wall between the development and maintenance of a service.
Nevertheless, a microservice team’s autonomy will always end when it comes to the level of macro architecture. As soon as microservices start to communicate with other services, teams will naturally need to work with other teams, usually at the cost of their own autonomy. This macro-architectural communication needs to be defined by yet another team, in most cases the software architecture team (which may have been relieved of a certain portion of its work, now that autonomous teams are handling their own architecture).
SEE ALSO: The speed of microservices
Finally, you may have already encountered the tenets of service-oriented architecture: Boundaries are explicit; Services are autonomous (not just in terms of teams, but also in their runtime); Services share scheme and contract, but not class; And service compatibility is based on policy. Sounds a lot like microservices, right? A final, positive lesson comes from Dennis Schulte, who tells us that “microservices are actually SOA done right”.