More thoughts on container-less development

It's time to get back to the concept of container-less development. I gave an outline of my thinking a while back, but let's remember that I'm not talking about containers such as docker or rocket, though they do have an impact on the kinds of containers I am concerned about: those typically associated with application servers and specifically Java application servers. Over the years the Java community has come to associate containers with monolithic J2EE or Java EE application servers, providing some useful capabilities but often in a way which isn't natural for the majority of Java developers who just "want to get stuff done."

Now of course those kinds of containers did exist. Probably the first such container was what came out of implementing the J2EE standard and that itself evolved from CORBA, which despite some bad press, wasn't as bad as some people make out (though that's perhaps a topic for a different entry.) CORBA was based around the concept of services, but back then natural unit of concurrency was the operating system process because threading wasn't a typical aspect of programming languages. Early threading implementations such as using setjmp/longjmp or Sun's LWP package for SunOS/Solaris, were very much in their infancy. When Java came along with its native support for threads, CORBA was still the popular approach for enterprise middleware, so it was fairly natural to try to take that architecture and transplant it into Java. What resulted was the initial concept of a container of interacting services minus the distribution aspect to improve performance. (It's worth noting that the success of Java/J2EE, the inclusion of Java as a supported language for CORBA, and the increase in thread support for other languages resulted in a reverse imitation with the CORBA Component Model Architecture.)

Now of course there's a lot more to a container these days than the services (capabilities) it offers. But in the good 'ol days this approach to kickstarting the J2EE revolution around CORBA resulted in some inefficient implementations. However, as they say, hindsight is always 20/20. What exacerbated things though is that despite gaining more and more experience over the years, most J2EE application servers didn't really go back to basics and tackle the problem with a clean slate. Another problem, which frameworks such as Spring tried to address, was that CORBA didn't really have a programming model, but again that's for another entry.

Unfortunately this history of early implementations hasn't necessarily always had a positive impact on current implementations. Change can be painful and slow. And many people have used these initial poor experiences with Java containers as a reason to stay away from containers entirely. That is unfortunate because there is a lot of good that containers mask and which we take for granted (knowingly or unknowingly.) They include things such as connection pooling, classloader management, thread management, security etc. Of course as developers we were able to manage much of these things before containers came on the scene and to this day. CORBA programmers did the exact same thing (anyone remember dependency hell with shared libraries in C/C++?) But for complex applications, those (in a single address space) that grow in functionality and typically built by a team or from components built by different programmers, handling things yourself can become almost a full time job in itself. These aspects of the container are useful for developers.

It's important to understand that some containers have changed for the better over the years. They've become more streamlined, fit for purpose and looking at the problem domain from a whole new perspective. The results are lightweight containers that do a few core things that all (majority) developers will always need really well and anything else is an add-on that is made available to the developer or application on an as-needed basis. The idea is that typically any of these additional capabilities are selected (dynamically or statically) with the understanding of the trade-offs they may represent, e.g., overhead versus functionality, so the selection to enable them is made as an informed choice rather than imposed by the container developers. Very much like the micro-kernels that we saw developing from the old monolithic operating systems back in the 1980's. So even if you're not

a Java EE fan or don't believe you need all of the services that often come out of the box such as transactions, messaging and security, the container's probably doing some goodness for you that you'd rather not want to handle manually.

Apart from the complexity and overhead that containers may provide (or are assumed to provide), there's the ability to dynamically update the running instance. For instance, adding a new service that wasn't available (or needed) at the time the container booted up. Or migrating a business object from one container to another which may require some dependent services to be migrated to the destination container. Or patching. Or simply adding a more up-to-date version of a service whilst retaining the old service for existing clients. Not all containers support this dynamism, but many do and it's a complexity that does not come without cost, even for the most efficient implementations.

Whether or not you agree with it, it should be apparent by now why there's a growing movement away from containers. Some people have experienced the overhead some containers impose for very little value. Some people haven't, but trust the opinions of their colleagues and friends. Still others have never been keen on containers in the first place. Whatever the reasons, the movement does exist. And then along come the new generation of (different) containers, such as docker and rocket which some in the container-less movement believe obviate the need for old-style containers entirely. The argument goes something like this (I'll use docker as an example simply because if I use the term container here it will become even more confusing!): docker produces immutable images and is very easy to use, so rather than worry about creating dynamically updateable containers within it, the old style "flat classpath"/container-less development strategies make more sense. In other words, work with the technology to get the best out of what it provides, rather than try to do more that really doesn't make sense and give you any real benefit.

This is a good argument and one that is not wrong. Docker images are certainly immutable and fairly easy to use. But that doesn't mean they obviate the need for Java containers. You've got to write your application somehow. That application may be complex, built by a team or built from components created by developers from different organisations over a period of years. And the immutability aspect of docker images is only true between instantiations of the image, i.e., the state of a running image can be changed, it's just that once it shuts down all changes are lost and any new instance starts from scratch with the original state. But docker instances may run for a long time. If they're part of a high-availability instance, with each image a replica of the others, then the replica group could be running indefinitely and the fact that changes occur to the state of one means that they are applied to the others (new replicas would have their state brought up to date as they join the group). Therefore, whilst immutability is a limitation it's no different than only having an in-memory database, for example, which has no persistent backing store: it can be architected around and could be a performance benefit.

If you believe that the mutability of a running docker instance is something that makes sense for your application or service, then long running instances are immediately part of your design philosophy. As a result, the dynamic update aspect of containers that we touched on earlier immediately becomes a useful thing to have. You may want to run multiple different instances of the "same" service. You may need to patch a running instance(s) whilst a pre-patched image is deployed into the application or replica group (eventually the pre-patched docker instances will replace the in-memory patches versions by natural attrition.)

And then we have microservices. I've said enough about them so won't go into specific details. However, with microservices we're seeing developers starting to consider SOA-like deployments for core capabilities (e.g., messaging) or business logic, outside the same address space of other capabilities which would normally be co-located within the Java container. This is very much like the original CORBA architecture and it has its merits - it is definitely a deployment architecture that continues to make sense decades after it was first put into production. But microservices don't remove the need for containers, even if they're using docker containers, which is becoming a popular implementation choice. As I said in my original article on this topic, in some ways the operating system becomes your container in this deployment approach. But within these docker instance, for example, containers are still useful.

Now of course I'm not suggesting that Java containers are the answer to all use cases. There are many examples of successful applications that don't use these containers and probably wouldn't have benefited much from them. Maybe some microservices implementations won't need them. But I do believe that others will. And of course the definition of the container depends upon where you look - just because it's not as obvious as the traditional Java container doesn't mean there's not a container somewhere, e.g., your operating system. However they're implemented, containers are useful and going container-less is really not an option.

Container-less development

In the Java world been hearing a lot lately about container-less development. (Note, I'm not talking about containers such as docker.) Whether it's to help build microservices, to reduce complexity for Java EE developers, or some other reasons, moving away from containers seems to be the theme of the day. One of the core aims behind the movement away from containers appears to be simplifying the lives of application developers and that's definitely a good thing.

 In general anything we can do to improve the development experience is always a good thing. However, I worry that the idea of moving away from containers is not necessarily going to make the lives of developers easier in the long term. Let's spend a moment to look at some of the things we've heard as complaints for container-driven development. I'll paraphrase, but ... "They make it too complex to do easy things." Or "Containers are just too bloated and get in the way of agile development." Or "The notion of containers is an anti-pattern from the 20th century." Or even "Testing code in containers is just too hard."

Now before we try to address these concerns, let's look at something I said to Markus in a recent interview. "Any container, whether it's something like docker, the JVM or even a Java EE application server, shouldn't really get in your way as a developer but should also offer you the capabilities you need for building and running your applications in a way that is easy to use, understand and manage. If you think about it, your laptop is a container. The operating system is a container. We take these for granted because over the years we've gotten really really good at building them to be unobtrusive. Yet if you look under the covers at your typical operating system, it's doing a lot of hard work for you and offering you capabilities such as process forking and scheduling, that you don't know you need but you do need them."

It's easy to make blanket statements like "containers are bad for agile development" or "containers are not fit for modern web apps", but the reality is somewhat different. Of course there may be specific examples of containers where these statements are correct, but let's try and remain objective here! As I mentioned to Markus, we're using containers in our daily development lives and not even aware of them most of the time. A good container, whether an operating system or a Java EE application server, shouldn't get in your way but should be there when you need it. When you don't need it, it's sitting in the background consuming limited memory and processor time, perhaps still ensuring that certain bad things don't happen to your application while it's running and which you didn't even consider initially, e.g., how often do you consider that your operating system is providing red zone protection for the individual processes?

As I said, a good container shouldn't get in your way. However, that doesn't mean it isn't needed. Many applications start out a lot simpler than they end up. You may not consider security initially, for instance, but if your application/service is going to be used by more than you and especially if it's going to be available globally, then it's something you're going to need eventually and a good container should be able to either take care of that for you opaquely or offer a simple to use interface. In essence, a good (ideal?) container should be like your favourite operating system - doing things in the background that you need but don't want to really understand, and offering easy to use APIs for those services you do need.

For enterprise users (and I include Web developers in that category) those services would include security, data management (RDBMS, NoSQL), messaging (not everything will communicate using HTTP) and transactions (yes, some people may not like them but they're essential for many types of application to ensure consistency in a local and distributed case). I'm not going to suggest that there's any such thing as the ideal/perfect container in the Java world today. There are definitely some implementations that would want you to consider seriously looking at container-less solutions! However, there are several implementations that have made significant strides in improving the developer experience and pushing themselves into the background, becoming part of the substrate. And a number of developer tools have sprung up to help developers further, such as Forge and Arquillian.

If you consider what lead to the rise of containers, it wasn't because someone somewhere thought "Oh wouldn't it be good if I threw everything and the kitchen sink into a deployment environment". Believe it or not there was a time before containers. Back then we didn't have multi-threaded languages. Everything was interconnected individual services, communicating using bespoke protocols. Your application was probably one or more services and clients, again communicating to get things done. If all of these services ran on the same machine (entirely possible) then once again you could consider the operating system as your application deployment container.

These services were there for a reason though: applications needed them! The development of containers as we know them today was therefore a natural evolution given improvements in language capabilities and hardware performance (reduce the interprocess communication at the very least). Granted we may not have focussed enough on making the development of applications with containers a seamless and natural thing. But that doesn't obviate the need.

Consider the container-less approach. For some applications this may be the right approach, just as we've never said that container-based development (or Java EE) was right for all applications. But as the complexity of the application or individual service grows and there's a need for more functionality (e.g., caching or security) then application developers shouldn't have to worry about which caching implementation is the best for their environment, or which version works well with the other functional components they're relying upon. Eventually container-less frameworks will start to address these concerns and add the "missing" features, whether as interconnected individual (micro?) services in their own address spaces or co-located with the application code/business logic but (hopefully) in an opaque manner that doesn't get in the way of the developer. Once we start down that road we're heading towards something that looks very similar to a container.

Rather than throw away the inherent benefits of containers, I think we should be working to make them even easier to use. Maybe this requires changes in standards, where those containers are based upon them. Maybe it's giving feedback to the container developers on what's getting in the way. Maybe it's working with the container-less efforts to build next generation containers that fit into their development and deployment experience seamlessly. There are a number of ways this can go, but none of them are really container-less.