Alliances
1748129 Members
3684 Online
108758 Solutions
New Article
SFleischman

DevOps for Containers. Do it right – now!

Note from Steven Fleischman – This blog is the fourth in a series of five written by HPE Subject Matter Experts (SMEs) addressing topics related to Tanzu and containers that will be discussed during the HPE Roundtable at VMworld 2020. The title of the session is: “HPE Strategy with Tanzu for Containerizing Workloads.” (Session ID KUB3094S). It is scheduled for September 29, 2020 from 10:30-10:54 PDT in the Americas and September 30, 2020, from 11:30-11:54 CEST in EMEA. To attend this and other sessions at the event, we encourage you to register today.

containers 5 - September.jpg

 

Guest blogger: Rende Luitjes, Senior Hybrid-Cloud Technology Consultant, HPE Pointnext, Netherlands.

If you are not doing everything in the title already, what is holding you back?
Let’s face it. Your IT boss probably has DevOps and Containerization high on his or her agenda and is pushing you to go into this direction as well. So let’s take a quick look at some of the facts behind containers and their importance to DevOps. 

Old-School
Traditionally, applications would be developed and maintained by one team and rolled out to production by another team. Predictability of the roll out would greatly depends on the quality of the roll out instructions provided.

Failure to roll out an application update would lead to tension between the development- and operations teams. The operations team would blame the development team not to have provided detailed-enough instructions to successfully complete the roll out. The development team in turn would blame tight release-schedules and lack of insight and experience in the operations team. 

Dev-, test-, acceptance and production environments
To mitigate this challenge, different environments would be made available in which application release roll out can be validated. In the development environment, the development team would have a go at the roll out themselves. Advancing to the test environment, the roll out would be executed by the development team sitting shoulder to shoulder with the operations team. In the acceptance environment the operations team would be in charge, this time with the development team keeping an eye on things. In the production environment, the development team would not even present anymore and everything is up to the operations team instead. 

DevOps!
A good way to get around this is to have development and operational tasks driven by one and the same team, the ‘DevOps team. Just imagine this team producing documentation alongside automated test procedures, the application code itself and the roll out scripts, all in the same release bundle! 

Monolithic vs. Microservices
Traditionally, an application would be developed as a whole. When making a change in the code, the application needs to be taken down for maintenance and hopefully be put back in service with the long-awaited new feature and/or fix in place. Unless you apply strict guidance around this, a degree of trial and error will come into play. I present to you, ‘The Monolith’.

Imagine being able to re-factor an application into more logical sub-components, each managed individually. Making a change in one place, does not necessarily require you to take down the whole of the application. Instead, an update is rolled out on one of the components while the other keep performing their duties independently of one-another: ‘Microservices. 

Containerization
Applications to be built from scratch, should considered to be built using the Containerization approach. Doing it right – now!

Existing applications should be analyzed individually to validate if a change to a microservice approach is technically possible and above all, economically viable. If so, active functional development should be postponed and re-factoring of the application should be engaged until it is ready for roll out using microservices. 

Where should you deploy your application? Your virtualized monolithic application is probably hosted in your VMware vSphere infra-structure already. Good job!

As for hosting containerized applications, many choices are available. However, most have Kubernetes under the hood in one way or the other. Google sums it up perfectly:

Kubernetes is a platform for managing containerized workloads and services

Tanzu?
You probably expect by now to have to maintain a separate virtualization- as well as a containerization platform. Don’t worry. VMware has Tanzu, which is VMware’s platform that includes products and services to build, run and manage a Kubernetes environment from a single control point. 

Ci/Cd Pipeline
With the right infrastructure in place, release-bundles can then be deployed and tested, fully unattended. Starting in development, a fully contained environment is created in which the application code is pulled in and set-up using the accompanying roll out scripts. Once this is built, automated test scripts kick in and verify if the newly set-up environment is capable of passing all prepared tests 100% successfully.

If so, the contained environment is cleaned again and the exercise is then repeated in the test-, acceptance- and ultimately the production environment. All of this without any intervention from a living person whatsoever! 

Conclusion
Making the transition to DevOps using Containers may cost you more time to get underway, but it will save you a lot of time later. As an added bonus it will help you become more efficient and predictable to the business, and who doesn’t want that?!?!

For more information

The first three in this series of blogs on containers are all available:

These two blogs will provide you with additional information on HPE’s presence at VMworld 2020:

More general information on VMworld 2020 is available on the event site. You can learn more about the HPE – VMware alliance on our alliance pages.


Steven Fleischman
Hewlett Packard Enterprise

twitter.com/HPE_Alliances
linkedin.com/groups/6796618/
hpe.com/solutions

0 Kudos
About the Author

SFleischman

Steven Fleischman is the Senior Strategic Alliances Marketing Leader for Hewlett Packard Enterprise (HPE) and believes in a customer first approach. He has effectively managed, nurtured and built relationships with HPE’s largest and most strategic alliance partners. Using his in-depth partner experience, he has developed the alliance narrative encompassing thought-leadership, joint go-to-market strategies, sales and marketing initiatives across industries and channels. With over 20 years in the industry, Steven uses his creative thinking and problem solving skills to successfully manage and grow these partnerships. You can find him @Fleischmantweet