Blog

Private PaaS Transformation Is All About Apps, Not Infrastructure

By Atos Apprenda Support

butterfly transformation

Implementation of private Platform as a Service (PaaS) by its nature is a transformative project. By abstracting applications from infrastructure, developers are presented a self-service model of deploying and managing applications with profound business impact. Many companies are seeing applications deployed that would otherwise have been delayed due to resource management constraints, applications deployed in minutes rather than months, and increased utilization of their data centers.

Using a private PaaS drives innovation and reduces the cost of IT services, making internal IT in these organizations world class. This is based on a service model of providing faster innovation for applications, not infrastructure.

It’s the Apps, Not the Stack

As I work with companies to help them achieve these results, I see trends that are cause for concern when implementing PaaS. Companies are being asked to implement PaaS and at the same time transform their entire application stack to accommodate the PaaS.

In theory, this sounds enticing. You are already embarking on transformation to change the way you are deploying and managing applications, so why not simply consolidate your stack and simplify the application architecture at the same time?

Because in the real world, too much change at one time can hamper the adoption of PaaS and slow down your value proposition. We have found the best results when we move relevant existing applications over time, transforming the application development stack into a consistent pattern.

Those companies who have decided on transforming the entire development architecture have added risk and many have spent months in transformation with only a few applications actually on platform. This is not the way to fast value. PaaS should be a bridge where you get value quickly and lay the foundation for moving to a standardized architecture over time.

Three areas of concern regarding consolidating your infrastructure stack while embarking on a PaaS initiative:

1) Is the PaaS provider recommending the transformation because it is the right thing for your business or because they are prescriptive in the stack they need?

As Sinclair Schuller recently outlined, PaaS vendors can implement solutions outside of your current IT investments and run independently or they can integrate with your current IT investments. If a PaaS vendor requires you to run a specific stack based on their requirements or a legacy stakeholder, it should be cause for concern.

Forcing you to move hundreds, if not thousands, of applications off of current application servers or architecture patterns sounds great in marchitecture terms, but the reality of executing this strategy increases complexity and inhibits quick adoption of PaaS. This adds tremendous risk to your PaaS project and the reality is that moving all your applications to Tomcat or JBoss out of gate is a difficult task for any project.

The bottom line is do what is right for you and the resources you have. If it is to consolidate your development architecture stack, that is fine, but don’t do it because your PaaS requires you to do so. If you weren’t contemplating the move before, why would you double the transformation and risk of your PaaS project? Which leads to the second point.

2) Have you thought about the difficulty of both implementing a PaaS and converting hundreds of applications to a prescriptive architecture pattern?

If it would have been difficult without a PaaS, it will still be difficult with one. Who is going to do the conversion? How many resources do you have? Is the PaaS provider stating they will convert applications? If so, is it feasible for their service arm to move applications that may have been stagnant for some time to a new architecture?

The reality is, again, this sounds good in theory, but in practice we see PaaS implementations with the promise of moving current applications where they simply stall in their adoption because it is not economical to move applications to the prescriptive PaaS.

A strategy where you move applications as they are and then and only then do you take logical steps to decide which applications it makes sense to change architecturally. A PaaS should have the flexibility to run what you have and allow you to take advantage of PaaS today without needing a huge transformative project to move all the applications to JBoss or Tomcat at once. Which leads to the third and final point.

3) Are you losing innovation today because you are biting off more than you can chew?

Opportunity cost is real in PaaS. If I could have 200 applications a month moved onto a platform (Apprenda has a client that did just that) and receive benefits of scale, cloud architecture, faster deployment, utilization increases, and lower cost of IT Services, why would I not do that immediately? Why would I spend months and months converting applications to a standardized application server pattern?

Wouldn’t it make more sense to move the applications over to PaaS as quickly as possible and then decide which applications your organization can start standardizing? You can analyze what is best for your business and not what is prescribed by the PaaS you chose.

Doing both a PaaS and an architecture consolidation is really taking on two transformational projects at one time. Combining the two carries with it many risks, complexity, and lengthens the project timeline.

Apprenda’s Experience

At Apprenda, we work with large enterprise clients running hundreds, if not thousands, of applications on our platform. Because we work with large enterprises, it was important for us to integrate with technology being leveraged today, but give our customers and partners the opportunity to standardize technology on their terms, not ours. This fundamental difference has allowed us to onboard applications more easily and allowed for more developers to embrace PaaS. The only way to realize ROI in PaaS is if teams actually use it.

 

Atos Apprenda Support

3
View Comments
  1. TechYogJoshOctober 30, 2015

    Interesting article and again brings fore the confusion that is technology industry. A significant chunk of pundits will say “lift-and-shift” to a PaaS model will not deliver value unless the underlying application architecture is made “cloud friendly” to extract the cloud advantage. Whereas, it appears that Apprenda has taken a contra-view and is suggesting that enterprises should not risk too much change and focus first on shifting the existing stuff than shifting and transforming at the same time. Of course there are different clients who will adopt different strategies but “life-and-shift” has typically a limited lifespan. It just throws the can down the road but does not solve the fundamental problem. Moving to a private PaaS without meaningful underlying changes could produce short term benefits, however, may not be a true value driver.

  2. John GolkeOctober 30, 2015

    Josh,

    Thank you for the comment. A couple of things.
    1) The very nature of private PaaS does abstract and simplify the underlying infrastructure. So totally agree with what the pundits are saying here.

    2) I would not advocate a PaaS where you have no ‘future state’ of which middleware would be the end state (however, I would have two, not be prescribed one (see lock-in blogs))

    3) New builds of applications would adhere to these new architecture patterns

    However – in the enterprise – we have companies that are moving 1,000’s of applications on our platform. This is a bit different than other PaaS providers who sort of deploy application by application. In these companies, they may have JBoss apps, WebSphere apps, Tomcat apps, .NET and WCF services – and almost always have ‘all the above.’

    If you don’t have an economical way to move those apps on a platform without having to prescribe a Tomcat only middleware, for example, those apps may not ever move onto PaaS. That can be 80% of applications where it doesn’t make economical sense to refactor the application. What I am suggesting is that there is a lot of value left in moving those applications onto PaaS including the ‘cloud architecture’ and cloud patterns they gain by virtue of running in a PaaS run time like Apprenda. Additional savings in increased utilization, better SLA’s all by virtue of running in PaaS.

    Secondly, if the middleware that is prescribed has competition in two years by another middleware technology, do enterprises want to be locked into that prescribed middleware or have the flexibility to change over time? Also, in large enterprises with constant M&A activity – moving 1,000’s of additional applications as you acquire companies might not be feasible.

    I would advocate
    A) having a longer term end state of one or two middleware standards
    B) new builds of applications would adhere to these standards
    C) for non-standard middleware, I would still lift and shift these applications to gain the huge benefits of PaaS
    D) I would move these applications to the standard over time and only as the value warrants

    Thanks again for the response and this is my personal opinion from working with many large enterprises and organizations who are moving 100’s and multiple thousands of apps to PaaS.

    John

  3. John GolkeOctober 30, 2015

    PS:

    A losing strategy in my opinion is:

    Use opensource because its open: BUT applications won’t work from one fork to another AND you will have to use this version of OpenStack or this virtual provider if you want to scale the platform resources. So we will use opensource so we can have multi facets of lock in and be reliant on not only our PaaS provider to stay relevant, but also our cloud provider, middleware, Openstack provider etc. Plus I don’t have the flexibility to choose any cloud provider because I am limited by infrastructure choices. That is taking open systems and prescribing a lock in and creating a relatively monolithic stack – not a good recipe in my humble opinion for the enterprise long term. Compatible rather than prescriptive seems much more agreeable to my corporate clients.

Comments are closed.