The API Economy – Will containerization change the way you deliver applications at scale?
Containerization.
I’ve been hit with a wonderful containerization challenge recently. Write a review and suggestion for a beginning strategy for delivering software via IaaS utilizing a containerized approach. If you don’t know about containers, in a nutshell, CNAP or ‘Cloud Native Application Platforms’ allow the wrapping up of software, with all the dependencies, libraries and pre-requisites as a single ‘run time’ and then to be deployable via the cloud as a micro-service ((where feasible). Deploy once, deploy many, deploy anywhere, entirely stateless. Think Virtualization but without the OS. Or ‘headless’ as the fashionable saying goes this month!
Usually this would be a discipline deeply entrenched in DevOps of old, but now thanks to companies like Pivatol, Google, CoreOS and others, all are now all starting to provide entire turnkey platforms ready for the Enterprise. But there’s some massive issues in my opinion which I’ve started to discover not only as I utilize more CNAP delivery as part of my own toolset, but look into feasibility of it for clients.
My approach using Docker
Whilst benefits a plenty, from scalability to flexibility and with apps like Docker (which I use myself) providing a slick way to package them all up and deploy them across the entire SDLC, I’ve had a little bit of homebrew success, when it comes to deploying apps like my Fast Track Driving Test app, or my STD result app, where previously, I’ve had to run these on expensive on-prem infrastructure with bits of legacy code everywhere and dealing with a myriad of differing environments and struggling for compatibility. I used to have to entirely rebuild my whitelabel Driving App, dependent on the client because their infrastructure would be different. I used to have to completely rewrite and sometimes re-engineer my STD delivery app dependent on the Clinic because their technology stack would have certain pre-requisites example. It was a chore. So I started using Docker with a customized image entirely set up for the app, and I could make an odd tweak here/there dependent on the client need and then deploy it. There’s a great guide on using Docker here which I started with, if you’re interested.
Issues with IaaS and containers
There are also some issues to consider when it comes to containerization. You see, traditional infrastructure has been well, traditional for a long time, very mature, baked in costs, and difficult to change. Silverback Gorilla IT CIO’s know where they are with the hundreds of thousands they’ve spent on bare metal and at best, moved to the ‘cloud’ for specific workflows. But things are changing – software delivery is starting to demand scalable and variable apps at-pace and these two positions are entirely at opposed ends. People want software to work on the 1st click, from anywhere, at any time. So I see IT depts resisting container workflow because logistically its too tough, but business leaders with maybe not a full understanding demanding it without thinking. It’s all coming to a head.
Here’s some key issues
- Stateless containers don’t support integrated enterprise environments
The thing with containers is they are stateless. Yet traditional infrastructure does not work this way. So ultimately IT departments have to start considering building new infrastructure to support stateless and that’s a challenge.
- Legacy storage architectures typically don’t have API which means no automation
This is a big issue I see. You can’t automate old fashioned infrastructure and often ripping it out and starting again isn’t feasible so a question here is how much will it actually cost to deploy those apps in the ‘new world’
- Traditional IT and infrastructure is geared towards CAPEX, vendor lock-in and complex refresh cycles
Every company I’ve worked for lives in the world above, so you can’t just recommend IaaS and expect a company to throw out their existing infrastructure, but that’s the ask right?
A majority of companies (53%) surveyed by Cloudfoundry had either deployed (22%) or were in the process of evaluating (31%) containers. Organizations are moving rapidly to explore and adopt containers. Of the 53% who have deployed or are evaluating containers, 16% have “already mainstreamed” their use. Another 64% expect to mainstream the use of containers in the next year.
Gartner predicts by 2020, more than 50% of global organisations will be running containerized applications in production, up from less than 20% today.
Here’s what I’m starting to learn;
It’s called many things by many different IT depts and often gets shoved into ‘DevOps’ anyway. The technology is somewhat immature and there’s plenty of options from the likes of RedHat and Pivotal, but by golly you need to really make sure your business case is strong enough to really get the rest ROI from this approach to software development. In one of the last companies I consulted for, they wanted to run ‘containers’ but really didn’t have the infrastructure to accommodate it. I’ve put together some areas where in a nutshell I think you need to consider, if you want to adopt this form of software delivery in your production stack….
Monitoring
Whatever tool you use, makes sure you use both container and service level monitoring. Think of it like monitoring what’s going on in your VM and monitoring the Hypervisor also. Often I’ve seen lack of monitoring leaving IT teams flummoxed to what’s going on.
Security and Governance
Here’s something I’ve seen. And I think it’s an issue. With traditional virtualization, often your app would be on a dedicated VM, and any issues or attacks, it’d affect just that app. Still an issue, but won’t necessarily take your organisation down. With a shared OS host kernel, often if you get attacked, all your containerized apps are at risk. This is a massive issue. I have all my little homebrew technology running on containers using AWS, and a hardened OS. It’s patched and hardened within an inch of it’s life because I know if I get a problem, all my services go down at once. Imagine that at enterprise level and say your homebrew apps were a patient database, a drug analysis toolset, and a data analytic platform.
Storage
This is complicated. As it has to be transient too. It has to be API driven, scalable and burstable. This is often expensive. How to do you keep the resultant data created from a stateless app, whilst spinning down the storage. Moreso, where does that data go and how does it get transferred securely and quickly from microservice to microservice. This is not plain sailing whatsoever.
Container life cycle management
Sprawl. It becomes so easy to spin something up, you end up with stuff everywhere and not knowing what to do. The issue is intensified due to the fact there’s so many layers of services and tolling within each bit, this is going to cause a huge IT management issue and shouldn’t be considered as trivial.
Summary & Tips
If you’re in Enterprise land looking at outsourcing your Containerization approach, please consider the above and pick providers who are not only geared up to deliver a solution maybe wrapped up and/or, the more tech savvy may want to consider great online hosting providers such as Digital Ocean who I’ve personally had great success with, even if they are a bit expensive.
Infra-structurally speaking, you probably want to consider your existing real estate and understand where there are issues and what need to be done in terms of 1) investment and 2) compatibility. I don’t believe you can just shoe-horn Containers into a traditional landscape and besides, why do you want containers? Big question right there!
Remember, there isn’t actually any such thing as a ‘CNAP platform’ – what there are, is a range of platforms, delivery techniques, methods and software solutions which when integrated as part of a bigger workflow may allow you to scale your application delivery. And remember what it is you are actually containing. Most likely these will need rebuilding. Are you ready for that?
Interested in this or any other blog post, reach out to me on Twitter @mariodc
