DevNet Create: DevOps, Monoliths, and Microservices
DevNet Create: DevOps, Monoliths, and Microservices
See what one expert has to say on the state of DevOps best practices and how to start decomposing your monoliths into microservices.
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
For those of you who didn't go to DevNet Create last week, it was a pretty fantastic show. A major theme of the event was the role DevOps has played in modernizing software development and infrastructure, and many of the speakers had presentations that touched on that theme in one way or another.
Among the fantastic presenters at the conference was Anders Wallgren, CTO of Electric Cloud. His day 1 talk was titled Architecting Your App and Your Pipeline for Continuous Delivery — 5 Do's for Successful DevOps.
Our host Anders Wallgren, ladies and gentlemen!
As one would guess from the title, the talk focused mainly on some DevOps suggestions to make sure your projects more successful. That's increasingly important because, more and more, from refrigerators to cars, software is what is setting products apart.
"We differentiate these days largely on the basis of software," Wallgren said.
And how do you put out higher quality software in a given time? Well, there are dozens of answers to that, but the self-serving one I'm choosing for the purposes of this article is by embracing some key DevOps practices.
DevOps Best Practices
There's one simple question you can ask your product team to determine performance:
To what degree do we fear doing deployments?
More frequent deploys, as part of an organized CD pipeline, are generally a sign of the ability to successfully iterate on your product. What does success look like? In addition to more frequent deploys, you'll have shorter lead times, faster failure recovery, and a lower change failure rate. With that in mind, if your product team heads for the bunker every time you're about to deploy, that's what you'd call "a bad sign."
So, here are five important takeaways to consider when trying to utilize DevOps to improve your projects:
Have an artifact repo: "Can I go back?" is a fun question not to know the answer to. Having and using an artifact repository is a key component in allowing you to experiment and iterate in order to produce products of ever-increasing quality.
Have automated deployments: "Automate everything," Wallgren said. Automate your testing (and use smoke tests), automate your deploys, automate everything in the entire process. Manual tasks beget human error, and human error is the root of all evil. If you get to the point where someone says, "I can't automate that," it's likely that they either don't know how to automate it, or they feel it's not worth the time. Wallgren contends that it is very much worth the time.
Embrace self-service deploys: To that end, create and offer a deployment catalog for people to play with. Compile a group of tools and processes that your team can access quickly and easily to keep work flowing.
Embrace self-service environments: Likewise, make it easy for your team to spin up production-like environments at any point in the cycle. (Just remember to make it easy to tear them down when done.)
- Focus on security and audibility: As Wallgren put it, "You can't, at the end of your cycle, sprinkle security in." That's not the way the world works anymore. Make sure your pipeline focuses on security and audibility from the start so, if problems arise, there's a clear path you can travel to find them.
In addition, I'm going to leave you with a couple of slides that dealt specifically with containers and why they're great:
Breaking Down the Monolith: Design Patterns
Meanwhile, a significant chunk of Wallgren's talk focused on the gradual transition the industry has seen from monoliths to microservices. It goes without saying (which is why I'm going to say it anyway) that architecture is an extraordinarily important discussion to have early in the process.
After all, as Wallgren said, "It's hard to make an architecture un-suck."
I'm sure you know the pros and cons of both microservices and monoliths by now, so I'll forgo talking about them again. Rather, this section assumes you've decided that it's worth the time and dev cycles to break a monolith down into microservices. Therefore, I'll dedicate this part to sharing some key design patterns to consider for the job, courtesy of the presentation slides. (As a side note, DevNet Create should have the slides and many presentation videos up in the near future. They're probably going to be better quality than my phone's camera.)
Command Query Responsibility Segregation
The Saga Pattern
The Saga Pattern is all about event-based mechanisms. "You do one transaction here," Wallgren said. "If that succeeds, you issue another event."
With serverless, "State is the difficult thing," Wallgren said.
Backends for Frontends
And there you have it! That was a quick rundown of Anders Wallgren's talk at Cisco DevNet Create. During his discussion, he also touched on a few related topics, like the need for automated testing and utilizing containers and container orchestration tools. As he put it, "Manual testing is death to velocity," and (for containers), "Move the environment, not the code."
All in all, I thought his talk was informative, yet accessible. He made sure to dive into some useful, advanced topics while not losing the audience along the way. Either way, I hope you've enjoyed this recap and learned a few things about DevOps and decomposing monoliths into microservices!
Opinions expressed by DZone contributors are their own.