patpitchaya - Fotolia
Immature development tools, difficult legacy app modernization and nascent architectural models are the top challenges DevOps teams face in microservices development and building microservice architectures today, according to Craig Muzilla, senior vice president of Red Hat's applications platforms business. While not espousing a wait-and-see approach to developing microservices, he warned against overcommitting before technologies and frameworks evolve.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"Most of the microservices apps being created today are relatively simple, but they [will] get more transactional, more sophisticated," Muzilla said. "I'm not sure if all the developers are fully internalizing the magnitude of trying to manage that complexity."
As Red Hat's developer program leader, Muzilla regularly consults with software pros. In this Q&A, he shared the challenges that are vexing those involved in microservices development and managing microservice architecture projects.
What's the single biggest challenge in getting to a true microservice architecture?
Craig Muzilla: Legacy applications. Even getting those legacy applications into the cloud is a challenge. I'd say the bigger issue is that these complications [will] get more sophisticated in a microservices architecture. How [do] you govern all those pieces?
Consider the complexity of [an app] that might be comprised of hundreds, if not thousands, of little services. Think of making a change in one service, and that they're all autonomous. What will be the rippling effect of changing one service across the application? How do you build an architecture to manage this?
What is the worst case of complexity undermining microservices development that you've seen?
Muzilla: We haven't heard a ton of horror stories yet, because most people are still in the process of getting their first set of microservices up and running.
But some of the horror stories that we are beginning to hear relate to people who are containerizing everything. [For example,] there could be a security vulnerability in the core Linux that [could come up in] the containers, but they're grabbing the containers from all over the place and don't know how they've been affected. That's where some panic sets in. They don't know where their security breach has occurred. There might be thousands of containers deployed, and they don't know what has been affected. Then, the ability to update a security breach across all those containers becomes a monumental nightmare.
That problem with containers is something that most developers and even ops organizations have not fully grasped yet. They're starting to see it as like, 'Oh my gosh, there's another Heartbleed. There's a problem. I don't know where I'm exposed, because everything's been containerized and split out all over the place! I don't have a system to really control and monitor that.'
How can DevOps teams prevent these container security issues when developing microservices?
Muzilla: They need to have a disciplined process before creating their containers, systematically certifying them and scanning them to make sure they're safe. They need a basic understanding of the foundation of that container, how it was built and where it's running. They must be Linux [experts], because containers are basically Linux. Do they understand how that Linux was constructed and where it came from? Do they have [a Linux expert] who can make the security fix when it eventually happens?
Craig Muzillasenior vice president of Red Hat's applications platforms business
I think people are thinking that Linux is just completely abstracted, and they don't have to worry about it anymore. When [a breach] occurs, they're scrambling to catch up. So, [they need to focus on] having a process [and] having a system in place.
If you had to pick one place, where would you see the lack of microservices development expertise hurting organizations?
Muzilla: Some of the architectural and design practices for developing microservices-based apps are immature. It's easy for somebody to consider one service and create one service. You have some code and a little bit of a stack that you're putting that into. Maybe you have a container, and you fire it up and expose APIs, and your microservice is up and running. But in a company, the developer has to think about trying to orchestrate that microservice into something usable, like a composite application. I don't see that someone has figured out the best practices for that.
As I said, the [microservices-based] apps that are being created are still in nascent stages. There needs to be a context for developers and architects to use to know what it means to develop microservices in larger, more complex, composite applications.
Get advice on developing microservices and containers
Craig Muzilla talks Red Hat's open source strategies, VMware and more
Learn how Red Hat's platform director manages OpenStack deployments