CONTAINERS OR NOT, APPLICATION CENTRICITY IS THE KEY

While containers have stormed into the mainstream of ops infrastructure, it is now time to take a step back and think about how can you really leverage them to your advantage. You now have a very fast and effective “Ferrari” at a small percent cost, but is a container really what you need? Will you be able to handle it? Will it be an effective solution? Or only add more chaos to an already messy set up?
The world of containers is about immutability—use it then loose it. It is understood that fixing an infrastructure issue is more expensive than building a new one from scratch. While that is a great solution from a infra perspective, will it help allow an application to be delivered faster and with greater consistency? Will the business see a measurable difference in service levels?
Containers come and go, Applications are here to stay
In such a case, the focus has to be on Application centricity and building the container infrastructure to help manage applications in a very cohesive way.
What exactly does it mean to keep the container infrastructure ‘application centric’?
Below are a few thoughts I have put together – please feel free to add your thoughts in the comments:
  • Bundle all provisioning automation at the environment level, to ensure that at the container level automation is implemented into the core plumbing with minimal changes going into this layer. (Example: Have one common environment creation pipeline used to provision all environments, the composition of such a pipeline may have container creation as part of it – the end user sees only ‘create environment’ event for a given stage, without any nuances of what containers get created under it, or what existing servers get integrated)
  • Bundle all container actions at the application level, and then apply them at an environment level rather than taking action at the container level. Then forbid any action at the container level at all times. (Example: Action may be applying a security patch – you may actually create a new set of containers, but from an application perspective, you just applied a security patch)
  • Progress application environments across various life cycle stages by using containers or container compositions promoted to these stages. Proactive container (or container compositions) progression help creating clear view on what containers are available at what stage. (Example: All containers in a given stage are visible to the end user for him/her to ensure they can create new environments for that stage using them)
  • Roll-up monitoring events at application environment levels to ensure the environment is up on the whole, and use garbage collection heuristics to deal with the anomalies at the container level. (Example: an infra event at a container, needs to be handle at that level, while the health indicator does not worry about it unless it breaches application level tolerance)
  • Roll up all operational events like log-shipping, audit events, network policy management, secure access and validations all at the application level, then push into or pull from containers consistently.
  • Wrap running containers as application versions, such that the end user can get to the right version of the application without the nuances of containers and container ID, but by Application and Application Versions.
Hopefull this offers some food for thought in regards to how to leverage containers into yout infrastructure while keeping a laser focus on the application. Please offer any thoughts, ideas, or criticism in the comments below!

Comments

Post a Comment

Popular posts from this blog

Agile and The Moving Train

Back into the Blogging mood after long years! The reason is simple, I did not have much to share than the mundane stuff that kept on running for the last few years. I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world. First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are unders...
Read more

The joy of the journey

The software industry in India has really taken a toll on the IT employees. There have been plenty who are talking about exhaustion , retirement and moving out of the industry after 15+ years of hard experience. These are some of the stalwarts, greats who have done well for the IT service industry. The key reason has been that they have put in long midnight hours to bring a new project, work on bring the the projects into control and just executing this cycle with different pace, complexity and size but the cycle has been the same. When you take a step back at these instances, it is very evident that the industry will very soon take the exhaustion path unless we device a mechanism to bring in the joy of the IT journey at everything we do in IT. I have found less and less people who enjoy what they do, and always have a reason why they do not like what they do. The key is 'What is the joy factor of the Indian IT industry?'. Improving this is hard both individually and collectiv...
Read more

HOW SHOULD MANAGEMENT ENGAGE DEVELOPERS?

It was in one of those meetings, a senior leaders from a large company told me, ” You know, when I was a team lead, I had such a good time interacting with the team – I knew exactly what they are working on, how they were working and how I could support them. And I knew exactly how I can make a difference in their life. Today, I have a much bigger organisation under me, but I don’t know exactly what those individual contributors are working on? and no clue on how I can make a small difference to them and hence multiply those small differences to affect change in the company.” This got me thinking. He was absolutely right, the higher you go, the less you know about the individual contributors, but you have more individual contributors under you! “The larger your ability to make a difference, the lesser visibility will you have to bring that difference. An irony of life!” But I believe, you can actually make a big difference to these individual contributors even when a large orga...
Read more