DevOps Practice

App Mobility Is the New Use Case

Selling increased investment in DevOps is not always easy. It takes time to implement, resource away from other projects and inevitably there is cash outlay. If not done carefully, it also appears to introduce chaos, something most of us in IT strive to avoid.

But the benefits, at this point, are easy to document. Plenty of companies have tried and succeeded in moving to a more agile/DevOps approach to deployment. Yes, companies have failed, but the publicly acknowledged failures have also been dissected for lessons learned, which can help in your transformation.

Every advice site suggests tying DevOps/digital transformation to business goals, which is a good idea, but is harder to do most of the time.

Not any more. The truth is the future is mobile. Not as in mobile phones or cross platform (though both have a place in the future), but in the ability to run an app where it makes the most sense today with the knowledge that tomorrow there might be a better place to run it.

Historically, the architectural choices of yesterday’s teams become a burden on today’s teams. I’ve worked at a major insurer where a mainframe flat file DB system was keeping an application from moving. I’ve worked at a power company where we were not allowed to modify a system running on OS/2 because no one quite knew how to maintain it. I’ve worked at an energy services company where I spent a year trying to re-create Novell IPX solutions in an Ethernet environment…The list goes on.

What if we could avoid leaving such a legacy to future teams, and be more responsive to business needs/profitability in the future? That is, in a nutshell, what containers offer you. Today, you are running your app internally in a container management system. Tomorrow you’re running it on AWS in a container management system.

There are things to watch out for–most vendor-sponsored container management makes it very easy to use containers on their platform of choice, but difficult to move containers. IBM, as one of the least intrusive examples, offers integration with their proprietary tools. Once you’ve taken those integrations, your mobility/options are more limited. As I mentioned, IBM is one of the more open companies out there. They offer value for tying you down, but if you don’t need those services, it’s better not to use them so you can move the application at will.

Situations change, and containers allow for those changes. You may have a huge budget for external cloud apps today, but reasons ranging from internal cost decisions to regulatory changes could force your organization to reconsider options in just a few short months.

That makes mobility important to business. So does cost management. No matter what the cheapest architecture to deploy on tomorrow is, wherever makes the most sense is going to be a hit.

But how portable are they? Depends upon the app, and the implementation. An application that is developed as a group, able to run in a single pod (or multiple exact copies in multiple pods) is an easy thing to move about. One with containers spread across a variety of platforms, each doing what it is best at, will be more difficult to move. Persistent storage kind of guarantees that most enterprise apps have limited mobility–at least for the time being.

Any app that can be moved to the cloud can be containerized first, granting mobility that means no need for massive conversion efforts if the cloud doesn’t work out. Any app pulled back from the cloud to the DC has the same potential, the issue of where the data lives is real no matter what architecture is chosen for implementation. But for any app that can be moved, it can be put into containers and moved far more easily in the future. For many apps, it is simply dropping it into the new environment and configuring networking to route traffic to the new location.

We’re already going to leave future teams with a hodge-podge of databases, programming languages and networking tools such as WAF/load balancing. Let’s make life a little easier on them, and help increase the use of DevOps, by deploying with containers and targeting whatever makes sense for the org today, secure that tomorrow that can change and our burden will be less than it might have been.

Don Macvittie

Don Macvittie

20 year veteran leading a new technology consulting firm focused on the dev side of DevOps, Cloud, Security, and Application Development.

Recent Posts

Building an Open Source Observability Platform

By investing in open source frameworks and LGTM tools, SRE teams can effectively monitor their apps and gain insights into…

10 hours ago

To Devin or Not to Devin?

Cognition Labs' Devin is creating a lot of buzz in the industry, but John Willis urges organizations to proceed with…

11 hours ago

Survey Surfaces Substantial Platform Engineering Gains

While most app developers work for organizations that have platform teams, there isn't much consistency regarding where that team reports.

1 day ago

EP 43: DevOps Building Blocks Part 6 – Day 2 DevOps, Operations and SRE

Day Two DevOps is a phase in the SDLC that focuses on enhancing, optimizing and continuously improving the software development…

1 day ago

Survey Surfaces Lack of Significant Observability Progress

A global survey of 500 IT professionals suggests organizations are not making a lot of progress in their ability to…

1 day ago

EP 42: DevOps Building Blocks Part 5: Flow, Bottlenecks and Continuous Improvement

In part five of this series, hosts Alan Shimel and Mitch Ashley are joined by Bryan Cole (Tricentis), Ixchel Ruiz…

1 day ago