When faced with the challenge of figuring out how to move applications to the cloud (on-prem or public), many people struggle.
They struggle for the following reasons:
1. They have application portfolios with hundreds (or even thousands) of apps.
2. They are buried in a sea of technology options and don’t know where to start.
3. They have next generation considerations (what to do for their cloud-native strategy) and existing app considerations (what to do with things developers have built in prior years).
4. Not everyone is retrained on cloud (for example, most new app development in the enterprise isn’t using microservice patterns, etc.)
This dynamic is worsened by the fact that opinions run rampant on what makes a tenable cloud strategy. Some say to forget the past and only focus on cloud native, while others tell you to abandon IaaS in favor of PaaS or to do everything in the public cloud. These dogmatic views are likely to be incorrect and lack calibration around the constraints and day-to-day issues faced by people exploring how to introduce cloud organizationally.
Generally speaking, the same people with the highly dogmatic opinions are also the ones who typically advocate a highly constrained view: “PaaS is the only option” or “PaaS isn’t needed” etc. The reality is that there is no single tool to bring all apps to cloud (and no, rewriting all the apps in an app portfolio is not an option), no single delivery model (on-premises or public), and no magic bullet. There is no “one size fits all” approach.
So what does reality look like, then, for someone who wants to deliver maximum value to their app portfolio? In order to be successful in cloud, any smart strategy needs to incorporate multiple technologies and the appropriate guidance on applicability. One place to start is to understand that the value any given application can extract from a cloud technology is inversely proportional to how broadly applicable that cloud technology is to any new or existing app. That is, the more apps a technology can support “out of the box,” the less value it likely provides any individual application.
Given our goals at Apprenda, focusing on the interplay between different types of cloud platforms is a place to start. IaaS and cloud platforms are not an “either/or” strategy, but they can be a “both” strategy.
IaaS is good at generalizing support. Most apps have no issue running on IaaS, but the value they extract is minimal relative to other options. Apps don’t suddenly become available or elastic and they don’t get services like log aggregation “for free.” (They may not be able to take architectural advantage of being on IaaS, but they can certainly run on one). The more architecturally abstract platforms are generally more opinionated, reducing the number of apps that are out-of-the-box compatible, but they also drastically increase the value any compatible app may realize by running on that platform.
At Apprenda, we’ve invested in building cloud technologies that support both traditional app patterns as well as cloud-native patterns. In turn, we provide our customers the following guidance: maximizing value across the app portfolio is achieved by ensuring that each application is deployed to the most abstract platform that will accept it with little to no rewrite. By doing so, cost for each app is minimized and value is locally optimized (in some cases, a rewrite is warranted to achieve a global value maximum). Although more nuanced in practice, a general decision framework can be overlayed on a multi-technology approach that looks a bit like this:
This sort of thinking helps alleviate some of the pressure experienced by someone implementing a cloud strategy since it acknowledges that multiple tools can be used. It also makes it clear that an organization needs to approach the app portfolio and not just a single app, and that both existing and new apps are important.
Questions? Leave a note in the comments below or connect with me on Twitter at @sschuller.