Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Why building microservices may call upon your gardening skills

What do microservices and landscaping have in common? In this piece, one microservices-oriented CTO shares tips for their creation, including how thinking like a gardener can help.

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."

It's about good, object-oriented design.
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."

Next Steps

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

This was last published in July 2016

Dig Deeper on Managing microservices architectures and SOA

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Do you have any helpful metaphors you use to describe your microservices architecture?
Cancel
I'm only seeing the gardening metaphor used in one tiny part. Shouldn't the final one, for example, suggest that developers "harden off" their new creations by exposing them, little by little, to the light of day?
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close