InfoQ | February 5, 2015

Virtual Roundtable: The Role of Containers in Modern Applications

JP Morgenthal recently published a controversial article entitled “Containers Are Designed for an Antiquated Application Architecture.” After observing a lively debate on Twitter, InfoQ reached out to some of the most influential (and opinionated!) tech leaders in the industry – including Morgenthal himself – and asked them to participate in a virtual roundtable. As expected, this discussion proved lively and informative as the participants challenged assumptions and brought clarity to a popular, and misunderstood, topic.

Participating in this roundtable are:

  • JP Morgenthal – Director, Cloud & DevOps Practices at Perficient
  • Brent Smithurst – Vice President of Product Management & Marketing at ActiveState
  • Krishnan Subramanian – Director of OpenShift Strategy at Red Hat
  • Dan Turkenkopf – Senior Director of Strategic Research at Apprenda
  • Andrew Clay Shafer – Senior Director of Technology at Pivotal

InfoQ: Let’s level-set first. In JP’s article about containers and legacy architecture, he describes cloud-scale apps and how they differ from traditional n-tier apps:

  • “Cloud-scale applications by nature are stateless with any application state being managed by cache or database services. The compute unit of measure is the process not the CPU, which enables greater scalability. “
  • “They are typically built on languages with runtimes that operate across multiple operating system and platform-as-a-service environments.”
  • “Cloud-scale apps leverage HTTP/S as their primary means for communication.”
  • “Cloud-scale applications actually require fewer custom components to deploy making them easier to manage over time”

Do you agree with these characteristics? How else would you classify a cloud scale application? What about management aspects?

Krish: I call applications that are stateless and the state managed by cache/datastores as cloud native apps. Cloud-scale apps, in my opinion, confuses people with a new term. We already have web scale to denote apps that are cloud native and have a scale like Google, Amazon or Netflix.

I categorize apps as follows:

  1. Cloud Native Vs Traditional based on how state of the app is managed (Stateless vs Stateful)
  2. Monolith vs Microservices based on functional distribution

Having made this clear, I agree with JP that cloud native apps are stateless and can be scaled out seamlessly, polyglot and uses REST for communication. However, I am not sure if I agree with his characterization that such apps require few custom components. With right automation and suitable management tools, cloud native applications with custom components can be easily managed.

Even though I would claim that PaaS is a suitable level of abstraction for cloud native apps (of course, with my OpenShift hat on), there could be instances, especially at web scale, where IaaS+ approach might work better.

Dan: I agree with Krish that “cloud-scale” isn’t necessarily the right term. There are many applications that can and do benefit from running on cloud that don’t need tremendous scale.

That said, JP does a great job in capturing the cloud application patterns of statelessness, HTTP/S and location transparency (which I’ll define a little bit more broadly as the ability to run on multiple providers).

On the topic of microservices, I’d like to distinguish between the packaging/deployment aspect and the architectural aspect. It seems the packaging and the containerized deployments get most of the press, but the real value to me is driving a loosely coupled, componentized system with each component having a single responsibility. That’s what allows you to maintain a flexible, adaptive application. As long as you have the right automation and process, it doesn’t really matter if you deploy a bunch of individual services or a large monolith (see Etsy).

InfoQ: Dan pointed out that a real key to modern cloud applications is loose-coupling and single-responsibility components. While this pattern can be realized in many different runtimes (e.g. virtual machines, traditional PaaS), do containers (positively) steer you towards this architectural style?  What role do containers play in facilitating modern cloud solutions?

JP: I don’t believe containers have a direct correlation on architecture. They can be used to package an entire application or a single component. The point I make in the blog is that whichever way you decide to use them, you are carrying around the necessary operating system and application dependencies scaffolding to make that package operational. Containers are designed to be task-based, which is why you always need a foreground process active or it will terminate. We turn them into daemons by adding simple dummy loops to keep them alive. These are not mini-servers. They are complex processes and as such their work could much better be carried out by a combination of PaaS platforms and using existing cloud services.

Dan: Containers might make you think a little bit more about how to separate your application into smaller execution units, but, as JP says, that’s not a hard and fast requirement for using a container. You can still build a monolithic application in a container as long as you have a single process to launch (which really could just be a script that launches a bunch of background processes).

And, while containers are great for runtime isolation of components and portability, they are absolutely the wrong level of abstraction for application development and deployment.

Developers should identify the capabilities their applications need and not care about how the implementation is provided. The container patterns on the market force an understanding of the full stack that delivers those capabilities.

As Krish’s colleague Thomas Qvarnstrom points out – once you build a container, you essentially own everything underneath the application. Yes, you can leverage existing images to assemble a stack, and there are ways to ensure a new deployment will get a new version of your dependencies (woe unto you if the versions aren’t backwards compatible though), but the developer is now responsible for maintaining what’s really a full application hosting environment.

To be frank, most developers don’t have the experience, and more importantly, the desire to fulfill that responsibility individually or in small groups. A runtime platform lets developers worry about their application, and identifying their needs, and lets other developers or operators supply the pieces that fulfill those needs. While cross-knowledge and empathy between all team members is clearly important, specialization of labor arose for a purpose. A platform allows for the accumulated experience to be applied where necessary, and creates a lingua franca to translate across expertise boundaries – in a way that would be extremely difficult in a container based system.

InfoQ: Let’s talk about the reality of technical debt and where developers are today. I think it’s fair to say that many (most?) enterprise app portfolios are dominated by commercial, packaged software from the likes of Oracle and Microsoft (not to mention all the small ISVs that solve specific problems). Should orgs write those apps off when it comes to plotting out new, scalable architectures, or is there a way for legacy applications (and delivery models) to co-exist with modern apps in a more agile, container-based, microservices world?

JP: There’s a lot of complexity in this question. For one, I don’t believe there’s a dominant pattern for application portfolios across enterprises. I have found businesses that exist solely on one end of the spectrum (all custom or all COTS) as well as a mix of both. When it comes to technical debt COTS raises some interesting dilemmas. Many businesses have spent millions (tens of millions?) on customizing these COTS packages to do what they need. It’s a difficult investment to walk away from. Yet, there is significant technical debt captured within the bounds of those implementations. Some of that debt belongs to the software vendor and some belongs to the businesses themselves. It would be great if it was as simple as delivering microservice abstractions to reduce reliance on these systems and enable the business to move to a more modern platform. However, the underlying systems themselves don’t make this simple. Moreover, in many of these cases the choices for replacement aren’t significantly better. That said, I know of one business that underwent an IT Transformation and paid off their technical debt by switching to SAP from Oracle. Their choice allowed them to deploy using all virtual servers running on a cloud architecture with expected costs savings of $66 million versus what they would have paid if they continued on the old platform over the same time frame. In this case, moving to a scalable and more maintainable architecture was a difficult choice, but well worth the cost.

Technical debt continues to accrue interest and will continually eat away at monies that can be used to drive competitiveness and agility. It will be difficult for businesses to focus on investing in new modern scalable architectures while having to maintain their legacy debt.

Brent: I’m not sure you can generalize that commercial, packaged software dominates enterprise app portfolios. Well, perhaps you can, but you’d need to point me to a study proving this. Maybe it depends on what type of software you’re referring to, or even in which department — obviously, commercial database software from Oracle, Microsoft, and others are extremely common. The enterprise (Fortune 1000) developers we speak to have huge numbers of custom applications written in various languages. Those may need to access data and store data in a commercial package, but they’re still custom applications that can be written or re-written to take advantage of a more cloud-native architecture.

Even with a commercial CRM or ERP system, many dozens of applications probably exist to extract and process or report on data, or to integrate with other systems. As JP says, these can be customizations to commercial software or they could be completely custom for just that organization.

If I’m understanding the question correctly, then I’d say, yes, legacy applications (such as a commercial ERP) can co-exist with modern, microservices based applications. In fact, re-writing some of those integration points to be more loosely coupled would be a good way to start eliminating technical debt and open the door to migration to a more modern platform. However, this isn’t going to be easy!

Dan: I’ll add my voice to Brent and JP questioning the fraction of the application portfolio represented by packaged software. But I’m also a little confused by the question. Buying something to fulfill a function that’s not core to my business is not what I would consider technical debt for the purposes of this conversation. Maybe it’s a decision I need to revisit (and move to a more nimble SaaS vendor), but my degrees of freedom to “fix” the problem are relatively limited.

The question of legacy and technical debt is much more meaningful in the custom application development realm. There, we should separate application design and agility from hosting and operational efficiency. Robust existing application systems that may not be amenable to rapid changes to their internal logic or structure may still benefit from aspects of the “modern” world. If they can be hosted on shared infrastructure, their developers given self-service deployment capabilities, and their operators given a common mechanism for managing all applications, then the operating efficiency can improve – reducing cost of ownership.

I also want to take some issue with the presumption at the end of the question that the modern approach will be or even should be containers and microservices. I mentioned in my previous answer that I think containers are the wrong level of abstraction for app development (even if they’re the right approach for application hosting), and I think microservices will work on the micro level but not the macro (see what I did there?) By that I mean that I think they’re an intriguing way to design applications within organizational boundaries, but I think we’re a long way away from the organizational change needed before one LOB takes a development AND runtime dependency on another LOB. Companies might get there, but I don’t think it’s a given.

InfoQ: Dan’s opinion has been clear that containers are the wrong abstraction for application development (and deployment). Taking this back to the original topic — are containers designed for an antiquated architecture model? — what’s the best abstraction for developers to use when building/deploying scalable modern applications? Is a PaaS? A PaaS with support for Docker-style containers? Something else?

Krish: Containers are not the abstraction for application development or deployment. It is the right encapsulation for applications and the deployment is aided by orchestration and other components. Most of the modern enterprise PaaS offerings use containers as the encapsulation component underneath. The way I will look at the question is “Should one use an equivalent to IaaS+ for application orchestration and management or take the PaaS route?”

The answer is it depends. There are some instances where IaaS+ kind of approach to containers might be the right approach and, for most cases, PaaS is a good abstraction. Technically, one can achieve the same end goal with the container services offered by Amazon and Google by using the right tools along with it. What PaaS does is to take out the operational complexity and provides a more standardized abstraction. I also want to quash a myth advocated in sections of industry that the use of containers (whether it is Docker or some other form of container underneath) takes away the abstraction provided by PaaS. It is pure FUD and there is no evidence to support such claims unless you categorize it under marketing.

Whether it is Docker or some other container format is the choice of different vendors. Every vendor will have their own reasons and their own marketing reasons to justify the choice of the underlying container. As an end user, it is up to you to decide what fits your organizational needs and go with it.

Dan: Let me clarify my stance. I don’t think containers are the wrong way to deploy applications – quite the contrary. Containers are a great way to ensure application isolation on shared resources. I just don’t think that developers should be the ones dealing with the containers. Which then of course speaks to the introduction of a layer in the middle to translate between developer artifacts and the containers. I believe you can make this platform approach work for both existing and new applications – you’ll just get more capabilities as a new style application.