Cloud & DevOps @ IBM
In the 110 years since its founding, IBM has constantly redefined itself, its version of success and its path to reach that high bar. IBM does this to stay relevant in an ever changing business climate, and the success speaks for itself as not many people, let alone companies, can claim to have survived two World Wars and several global economic recessions. IBM’s latest shift in strategy is to focus on cloud, blockchain, AI and quantum computing. It has divested part of its business and acquired Red Hat for $34 billion, a sign of its dedication to this new strategy. In this blog, we will primarily concentrate on what IBM is doing with Cloud and DevOps. In particular, we will give an insiders perspective on the relentless focus on cloud, delivering value with automation and how engineers have an opportunity to create ripples.
My name is Nitai Bashir, and I have been working as a DevOps engineer for almost 4 years.
Relentless Focus on Cloud
Businesses across industries are discovering the need to be in contact with the cloud as a powerful tool for transforming the way they add value to their customer experience. As a consequence, IBM works with an increasing number of clients to define their journey to the cloud by modernising their legacy applications or building/running cloud native applications. These projects can range from a small tech-enablement proof of concepts in IBM Cloud to large scale application migrations to AWS. In this vast space, there are two terms that get thrown around a lot: hybrid cloud and multi cloud.
Firstly let’s spend a moment to define these terms so that we are all on the same page:
- Hybrid Cloud: Applications and systems are deployed into a mixture of private, public and on-premise cloud platforms. This is usually considered when there is a strong business case to keep data secured in a particular location due to regulatory requirements.
- Multi Cloud: Applications and systems are deployed onto a mixture of cloud providers (e.g. IBM Cloud, AWS, Azure) taking advantage of different offerings, usually using only one type of cloud — public, private or on-premise. This strategy is implemented when there is a strong business case to aggressively reduce costs of the underlying platform.
A major thrust of IBM’s focus on cloud is to make Red Hat OpenShift the de facto tool for container managed solutions. It offers a number of advantages over other container management offerings, for example it has enterprise level support and offers Red Hat approved operators for quickly installing standard tools. Aligning to this strategy, IBM has commissioned a team of engineers to build proof of concepts for clients with two main objectives:
- Create a platform where clients can practically experience what it means to get their applications on the cloud
- Build an environment where IBMers can learn DevOps principles, languages and tools to a level where they can then work with clients
For the past year or so, I have had the privilege to work in this team therefore upskilling in various cloud providers, DevOps technologies and best practices. I must have successfully completed over 20 proof of concepts which gave me exposure to multiple clients, in particular an insight into where they are in the cloud journey and how IBM can help them progress to the next step. I have run training courses for clients, built cloud native Node JS microservices and used Terraform to build infrastructure in AWS, IBM Cloud and Azure. I joined this project as a team lead, and came in to enable more complex proof of concepts to be delivered faster.
To qualify for this position, I supported teams of up to 30 developers, tester and business analysts to deliver two versions of a mobile banking application. This was my most treasured DevOps experience. It was tough, high-pressure and a steep learning curve. We built a production ready application from scratch in 8 months — following all the compliance, regulation and security. IBM Cloud, Kubernetes (this was before we bought Red Hat!), Helm, Java microservices, Jenkins. But wait, why am I telling you all this?
IBM builds robust, resilient, and reliable cloud solutions!
In my experience, IBMers are more than just a bunch of certifications on the cloud. They can deliver tough, challenging and multi-dimensional solutions on the cloud, whatever that cloud might be for you. I share this experience with you to make it clear that I have gained my depth and breadth of skills in cloud and DevOps through practical application on projects — I don’t have a single certification! (albeit working on my Red Hat OpenShift one at the moment — leave a comment if you have any tips!) I have experienced a great deal in my short time with the company, and yet, because of their relentless focus on cloud, I have learned so much.
Delivering Value with Automation
In every sector, businesses are finding that value alone is not enough for their customers; value and speed must come hand-in-hand to constantly iterate on applications and deliver relevant features. One of the cutest implementations of automation is depicted in Disney’s Wall-E, where for over 700 years robots are left on Earth to clean up the planet so that humans could return. This robot had one mission, one purpose — doing whatever was necessary to get the task done! A fictionally highly evolved AI with near-human like characteristics.
For technology consulting companies, like IBM, this means that we have to be able to build cloud infrastructure with Terraform, test application features with Tekton pipelines and config vast systems with Ansible. These are but a few examples of how automation is causing seismic shifts in the market because, with it, clients can realise value much faster with their experiments.
These automation tools create systems of reusability, reliability and repeatability. The principles of automation and the technologies that enable it are at the heart of DevOps. I have already written a blog post on inspiring the DevOps culture and how you can start adopting automation now. Of the many benefits of automation, I would like to highlight two specific use cases:
- Automation enables developer productivity because environments can be built with speed
- Automation enables operations engineers because it codifies the platform infrastructure
Looking into more detail of the first use case, automated systems ensure that building an environment is reusable. In Gene Kim’s The Unicorn Project, a senior developer, Maxine, joins a sinking project and to her horror she finds that it takes months to build a development environment. I am sure we can all relate to some extent the pain she went through. Using infrastructure as code tools like Terraform and Ansible, building and configuring environments becomes a simple task of reusing the modules with environment specific configuration.
For the second use case, a key part of an automated system is to have reusability across the stack; this is achieved by codifying platform infrastructure. When working with a banking sector client, I used IBM Cloud Kubernetes to host a system of 50 microservices for a mobile application. I deployed the microservices with Helm, but I regret not codifying my platform resources with Terraform, for example clusters, load balancers, and API gateways. Inevitably, when the time came to build production environments I had to remember the steps we went through for dev! I learned that infrastructure as code is so valuable, and I have kept that close to heart till today. Automation for operations means to codify the underlying platform, just as developers write code for features in their applications, making the infrastructure builds repeatable.
We have detailed how automation can add value to technical engineers. This is only one aspect of a technology-enabled company. The other side of the coin is the business stakeholders: your customers, your leadership team and your company’s strategy. These three things are arguably more important than the tech that is used under the hood because they are the foundation to the system. Automation can add value to these three areas.
Exploring this in more detail and specifically addressing the two use cases raised above:
- Automation enables developers; therefore adding value to the customers because developers are able to deliver relevant features more regularly to the customer. In particular, having on-demand environments means that new production-like environments can be created quickly to test specific features or bug-fixes, or execute performance testing. This keeps fast flow throughout the technology enabled value stream.
- Automation enables operations engineers; therefore adding value to your company’s strategy because it brings consistency across the stack. In many traditional setups, there are a number of manual steps or scripts that need to be run to construct an environment, therefore codifying your resources ensures that there is consistency in environment setup. Your company is going to have a cloud strategy that will inform what you build for your environments, automating this brings everything under those guidelines.
In my experience of working on IBM projects, Cloud and DevOps engineers get hands-on with these automation technologies to deliver value to developers, system engineers and the client. Clients can practically see how this value manifests in their value streams, thereby allowing them to experiment more with features in their applications and test the resilience of their tech stack.
An Opportunity to Create Ripples
Coming to the conclusion of this post, hopefully you have got an idea of the breadth and depth of skills that IBM offers its Cloud and DevOps engineers. My experience is a testament to that. IBM is a huge technology consulting company and therefore the work we do has a direct impact on clients — not only do we help clients on their journey to the cloud, but we also lead transformation in ways of working to bring clients to an integrated DevOps culture. At such a large company, you get the same opportunity to make a difference and be part of a shifting market.
To finish, I will leave you with one final story of how I impacted the client over and above implementing DevOps technologies. For an industrial client, the IBM team put together a squad of subject matter experts to improve how the client developed their loyalty mobile application. They were transitioning to global market and round-the-world development teams, a big step to support their customers across the world. I joined this project, immediately identifying areas for improvement in their DevOps capabilities and then delivered value to the automation platform by reducing pipeline times and increasing pipeline reliability.
Immediately, this demonstrated how DevOps can be practically implemented to add value to the business since it enabled them to begin scaling up to global markets. The business saw how they could add features to their application reliably and support an application that was contributed to by a global development team. They began to launch in other markets outside of Europe. This got them hooked! We then opened up conversations about how they can implement the principles of DevOps in their Ways of Working to drive even greater change. Firstly, we agreed the biggest value item would be to upskill the development teams in the DevOps tools so that they can build the application and run it. The client then rolled out training across their teams to fill this skills gap. The success of this project was founded on demonstrating the importance of DevOps.
In all of IBM’s history, we have defined our goals for success. Now we have a relentless focus on Cloud, AI, blockchain and quantum — ultimately resulting in a wide variety of projects in all these areas. As a DevOps engineer, I have had the opportunity to learn the technologies driving change in the market and transformed the way that clients run the development teams.
Each engineer’s path is unique. What could you become at IBM?
