Applications are Gold

We’ve talked previously about how developers drive organizational success: they deliver the applications by which companies deliver their competitive advantages. Because they are a way for companies to deliver products to customers, those delivered applications are critically valuable. Application development is a lot like extracting gold – it creates value out of raw resources.

Application development is a lot like extracting gold – it creates value out of raw resources.

Gold, wealth, needs to have some amount of protection.

Protection

Applications are made up of two kinds of assets: the code and the architecture.

The Code

Protecting the value inherent in code, or what the application does, is pretty simple (…but not always easy!). You want to house it in a standardized source control management (SCM) tool, with versioning, and you want to regularly make sure that it can build (be turned from raw source code into something that can actually run on a platform). SCM with versioning matters so that a) you don’t lose your source code (a horrible alternative to this would be the source code just hanging out on someone’s computer…) and b) if you make a change you didn’t mean to make, you can go back to an older version. SCM means that the code gets to continue to exist – it’s the most fundamental of protections. The ability to build matters in part because it’s the only way to resolve a code vulnerability in an included library – basically, if you need to release a change to an application for some reason, building it is the first step after the code is changed, and the technical debt behind not building for a long time means that this can be a major bottleneck.

Open source-based products are the best plan for vital enterprise tools, for reasons we’ll explain in another post – but for a SCM, that means using something Git-based. The ability to build whenever you need to – or, said another way, releasing regularly and frequently – is solved via continuous delivery. Or…continuous delivery ish. Just…release more than never, okay?

The Architecture

Protecting the value of architecture, or how the application does what it does, both now and in the future, is…less simple. The best thing to keep in mind is to make sure that the application can run where you want it to run, how you want it to run. Scalability (how well it responds to growth, usually referring to the number of users, the amount of data it interacts with, or the processing it has to do), cost (how much the platform costs to run the application), portability (the ability to run on more than one platform), and performance (how well it responds) are all important here. The best choice we (IT as a whole) know of today for scalability, portability, and performance (…and usually cost) is container technology  Serverless technology is more scalable, and may be cheaper, but it’s still in its infancy and isn’t something most enterprises can support.

The best thing to keep in mind is to make sure the application can run where you want it to run, how you want it to run. The best choice we (IT as a whole) know of today to accomplish this is container technology.

Platforms

If applications are gold, then platforms, or where you run those applications, end up a lot like banks…if banks took gold directly. You need somewhere to store your gold, ideally where it’s still accessible and usable – because running around with bars of gold in your pocket isn’t entirely practical. Those suckers are heavy. Ideally, though, if at any point you need or want to move your gold to a different bank, you’d be able to do that without paying a hefty penalty. In IT, that penalty is usually time – time to refactor an application to successfully run on a different platform.

Imagine if the bank only allowed you to spend $50 worth of gold every day, despite having several thousand dollars’ worth of gold in there. If your gold is stuck in that one bank, with hefty penalties to move it, then it’s really only as usable as the features and rules of that bank.

Containers

Containers deliver on scalability and portability, better than anything else currently out there. You can run a container built on standardized, open technology (Docker, CRI-O) on almost any container platform these days – a cloud built to run on-premise (within a company’s hardware), or in any of the various public clouds. Then you need to be able to connect and orchestrate the containers (and deliver on that actual scalability), and Kubernetes is the standard for that. If you’re not building containers, and containers for Kubernetes, you’re risking a lot of lock-in: getting stuck using technology that doesn’t scale, isn’t flexible, or isn’t portable in the ways you’re going to want.

The Question

The question then becomes, which bank do you use? Where do you store your gold – the implementation of your competitive advantage – where you can have usability, but also portability and the right to find a different platform if you want to? And, for bonus points, since developers and the teams that surround them are the linchpin in all of this, how do you do all of that in a way that makes those developers and those teams super happy?

OpenShift!

We could be accused of being biased at this point, we do both work for Red Hat. But even before we worked for Red Hat, we loved OpenShift – and loving it as much as we do is how we ended up at Red Hat. The more we work with a variety of customers, the more we see that the beauty of a platform like OpenShift, and the ecosystem and partnerships that surround it, is that you can build a container stupid easy (using Red Hat’s source-to-image (s2i) technology), using implementations and frameworks you know and love (JEE, Spring Boot, NodeJS, etc…) or even architectures that give you even more power and scalability (Quarkus, Camel-K), and you can deploy that container anywhere you’d want to run it: AWS, GCS, IBM or Microsoft’s cloud, or on-premise in your own private cloud.

You end up locked into OpenShift – but only OpenShift. You have to choose some bank. And OpenShift is built to allow you to move your…well, your gold, wherever you want it to be.

TL;DR

A company’s applications are very much like gold – they’re wealth realized from raw materials. Protect your gold. Protect your rights to access and use your gold in the ways that will realize the most inherent value – and give you room to find more value than you even guessed was there. In the world of application development, that translates to open standards, source control, releasing frequently, and containers – Kubernetes and OpenShift, specifically. All of this works to help make sure that your applications, the execution of your competitive advantage, are as protected and valuable as they can be.