While automation is a huge part of creating a microservices architecture, there is nothing automatic about the...
task of actually building microservices. Doing so requires the formation of a clearly defined end-goal, well-thought-out tool implementation and strategic deployment practices.
We spoke with Daniel Rolnick, CTO at internet marketing and advertising company Yodle, based in New York, who has been "leading the charge" toward microservices and continuous delivery at this company. Read on to learn his tips for creating a strong microservices architecture, including why it helps to think like a gardener.
Define your goal with SOLID principles
"If you can't describe it in a simple sentence or a few simple sentences, it's definitely too big."
Daniel RolnickCTO, Yodle
Rolnick's first point of advice concerns the importance of determining a goal -- a very specific goal -- before delving into your microservices project.
"If you're going to go microservices, not just services, you really should have a clear definition for what you're doing with the microservice," he said.
He specifically stressed the importance of forming this goal around SOLID principles -- also known as object-oriented design -- a set of principles designed to help programmers create software that is easy to manage and expand upon.
"In good object-oriented design, every object should have a single responsibility," he said. "And you're taking that up to the service layer."
Think of microservices like a garden
"You can't drive your business forward if everything has to have a big planning meeting ahead of it."
When it comes to building microservices, Rolnick said organizations need to prepare themselves for continuous change and evolution. One big part of this, he said, is trusting your smaller teams to make decisions without having to get approval from above.
"You should [trust] your teams to [build] the right thing, with the right intentions," he said. "And if they haven't, it's OK, because it evolves."
One metaphor about microservices Rolnick has heard and likes, he said, is to think about it like gardening and landscaping. The manager would be the chief groundskeeper, and the other team members are individual gardeners. The gardeners can focus on their individual tasks, and the chief gardener can maintain a view of the entire garden, or service ecosystem.
"Sometimes, they put a hedge in the wrong spot and it's too big, and I'd like them to break it into a nice, smaller clustering of flowers," he said. "But that's OK, we can do that."
Keep those services independent
"Independence of services is key ... you don't want to have large call chains."
Rolnick highlighted decoupling as another essential part of building microservices. This is important, he said, so end callers are not disrupted by network traffic latency, services going down or any other number of variables.
"You have to start really designing for failure in mind with your application," he said. "Asynchronicity is really, really important, or at least designing for failure."
To do so, Rolnick recommended Hystrix, a latency and fault-tolerance library. He also recommended using reactive programming extensions, such as RxJava, which makes developers design in a way that enables decoupling.
Understand the complexity of the task upfront
"There are things like monitoring and testing that you really need to be thinking about in the beginning."
Losing the ability to grok the entire system is a major challenge to consider when building microservices, Rolnick pointed out. Often, the scale of the complexity that comes with microservices can be overwhelming for some, and preparing for that complexity is essential.
"That's where really understanding that scale is going to get away from you, unless you plan for it from the beginning," he said. "The network effect of all these services quickly gets away from people, and they don't realize it until it's too late."
As Rolnick said, management was simpler in the days of macroservices when IT depended on a single server, especially in the case of a crash. "Somebody might log in and start it back up -- that was easy."
The introduction of microservices, he said, creates a complex situation, where manual management is not a simple task, and organizations need to realize how much more complicated it is when compared with the monolith.
"You're talking about maybe thousands of services," he said. "Keeping that up by hand and understanding the complexity of the service graph is not something that is trivial anymore."
Anomaly detection is key
"Anomaly detection is really, really a challenging problem when looking at workloads."
When working with microservices, according to Rolnick, it's important to remember just because an application is up and running doesn't always mean the services are meeting business needs. He said organizations need to monitor key metrics that indicate whether the application is "evolving appropriately."
The key to this, he said, is implementing automated monitoring utilities as much as possible, paying close attention to these metrics and reacting appropriately when certain anomalies appear.
"If you see a 10% drop in traffic that's a normally peak time, that's surprising," he said. "You might want to take a look at that."
Rolnick does believe tooling is a big part of this anomaly detection process. However, he said he does not advocate the use of one particular tool. Rather, he said, it often makes sense to combine a number of tools.
"I don't know that there's necessarily one solution out there that you can use," Rolnick said. "Sometimes, what you need to do is bring multiple sets of tooling together ... different tools that have different views on the same data."
Keep things behind closed doors
"Nothing is 'Big Bang' anymore when you're in the microservices world."
Rolnick also advised thinking carefully about release phases when it comes to building microservices. While microservices empower software developers to be more nimble and push features with "reckless abandon," he advised this be approached as "controlled reckless abandon." This entails intially releasing features to production behind closed feature gates, where they are unseen by users. Doing so can help ensure business outcomes are not drastically affected until the team is confident in the release.
"All the good companies are doing this," he said. "Nothing's just released into the wild. Once you're ready for this feature to go live, then you start releasing it slowly."
Discover four reasons you may need a microservices architecture
Access our exclusive guide to microservices and containers
Test yourself with our quiz on creating a microservices architecture