A Generational Shift to Simplify Infrastructure
A Generational Shift to Simplify Infrastructure
To stay competitive, it's time to jump feet first into the cloud native world. If you're not sure where to start with your infrastructure, here's some advice.
Join the DZone community and get the full member experience.Join For Free
In the seemingly endless effort to mask infrastructure complexity for your development process, new cloud-native architecture delivers unprecedented simplicity.
When you’re building your business app, you want to focus on creating a delightful user experience, on implementing the killer features your users are waiting for, and on perfecting the gorgeous UI your customers will love. You want to develop quickly and then improve constantly. The last thing you want to do is get bogged down in a lengthy release cycle at every turn, worrying about how one minor shift could break the whole application or about whether you still have the right infrastructure to stably support it.
For decades, organizations have been looking for ways to simplify these structural complexities away from the app dev process. The opportunity cost of slow release cycles, coupled with the very real expense of maintaining data and compute infrastructure, means the businesses that figure out how to be nimbler and more efficient can gain substantial advantages over the competition. It’s very likely your organization is already making use of the cloud to try and accomplish this, but first-generation attempts don’t go far enough.
To really take advantage of the revolutionary flexibility the cloud can offer today, application development needs to move to a truly serverless cloud-native approach.
At this point, you may be thinking you’ve heard this before, as increased flexibility — and even specifically utilizing the cloud to achieve this — has long been a business priority. To understand the size of the changes that cloud-native architecture now enables, it’s helpful to put it in context and understand how we got here today.
Leaving the Data Center Business
Businesses have long wanted to leave the data center business behind them. Twenty years ago, this was done through an Application Service Provider (ASP), who would essentially remotely host your whole application infrastructure. This reduced some costs, but the as-a-service model really took off when Salesforce popularized it in more recent years, evolving cloud services from its ASP roots into something less enormous that more businesses could utilize.
As companies began to embrace the cloud, eager for the savings and the efficiency, giant, monolithic programs were simply moved wholesale to the cloud.
This meant that the overly complex procedures that governed application development went to the cloud right along with the program itself. Further complicating things, many organizations today can’t just standardize on a single cloud—they may be multinationals and need regional options for compliance purposes, or even just utilize multiple SaaS offerings simultaneously.
Even modern Java-based apps are monoliths, requiring everybody who touches any part of this one gigantic app to coordinate with each other before pushing any changes. It’s clear this first-generation approach brings along unnecessary baggage, and fails to take full advantage of what the cloud can offer today.
Do as the Digital Giants Do
When you look at Amazon.com, you don’t think of the website or infrastructure getting big regular “releases” because they’re changing all the time — once every 11.7 seconds as far back as 2011, and as much as once every second today. Or think of Android smartphones, which were infamous for being slow to update. There are still big OS releases, but for years, Google has broken out key services from the main release that they update continuously through the Play Store.
These are just a few examples — there are many others — to drive home the point that by making your services truly discrete, independent and flexible, you can update even massive apps continuously and avoid lengthy delays.
Past Solutions Can’t Cut It
The goal of moving quickly is not a new one, but first-generation attempts you may have implemented all face limitations.
Most development teams have moved from a Waterfall development cycle to an Agile one, allowing for rapid development efforts. But with only the dev team operating at this pace, it has just shifted the bottleneck, rather than removing it. This has necessitated the creation of an entirely new team in DevOps to try and manage the resulting organizational inefficiency.
Service Oriented Architecture (SOA)
SOA does move organizations to a focus on services, but in many cases, each of the services is still a monolith of its own and isn’t truly segmented. For example, if key services all make use of a single monolithic shared database that can’t be easily updated, you’re not going to be able to make changes to your services at speed.
Virtualization and Containerization
Virtualization does help — no longer is each machine a monolith of its own, as multiple versions of an OS can be run on a single machine. Containerization makes it even easier to package and deploy things in your virtual environments. While this reduces the complexity of hardware setups and can make life easier for your developers, by itself it doesn’t address the time-consuming limitations of deploying services that are not independent.
How to Adopt Cloud Native and Serverless
It can be difficult to imagine making large changes to major mission-critical applications, especially if the platform governing it is monolithic and complex. But the more complex and mission-critical it is, the more benefit you can reap from going to cloud-native and serverless.
If you find yourself not knowing where to start, the easiest thing to do is pick a single project and implement it as cloud-native from day one, without changing your existing workloads. There’s no need to lift and shift — over time, you can gradually migrate more and more to the new environment. Even monoliths can call one microservice at a time, and then another and another.
Published at DZone with permission of Mark Troester , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.