Up-shift to the Cloud: Cloud Native vs. Legacy

This is the first in BroadPoint Cloud’s “Up-shift to the Cloud” series of blog posts

A Changing Business Landscape

Enterprises that have been in business for over 10 years tend to have a suite of business applications that were developed with a waterfall approach, following a monolith software blueprint. However, the rise of Cloud technologies has brought along the need for a mindset shift, and a digital transformation agenda that is at odds with the traditional ways of developing and deploying applications. 

Legacy Systems Challenges

Legacy applications are entirely designed, developed, deployed and managed in environments hosted and managed by traditional IT organizations – either internally or via managed service providers. Software development takes a one-size-fits-all-approach, usually in three-tiers that cover the Front-end: how people or outside sources interact with the application, Middle-layer: Typically encompassing all the rules that drive the business, and Back-end: Where all application data lives.

State and configuration are strewn across these tiers, and enterprises often break their own rules, for instance – by allowing front end components to directly access the back end, bypassing the middle tier. The drivers behind such expedient IT decisions are usually performance, resource constraints or even short term convenience. However, it doesn’t take long to add up, and over time lead to higher risk due to complexity, fragility, decreased flexibility, and - in almost all cases - a marked reduction in business agility and long term performance.

The Cloud Native Difference

Cloud Native “applications” on the other hand, are loosely coupled collections of services accessing decentralized data – not a single database – using a superfine approach, where independent microservices deliver individual business capabilities.

These self-contained services can be stitched together in endless combinations to create end-to-end business processes, composable on demand. The resulting agility enables capabilities to fulfill short term, long term and non-permanent business needs; and equally important – to decompose when business needs evolve, with zero impact to other components.

Cloud Native applications are “stateless” by nature. Configurations are localized, independent of technology employed by rest of the monolith, and provide a capacity to deploy components as and when needed.

Cloud Native vs. Legacy Architecture

Cloud Native

  • Microservices and container-based architecture

  • Agile and quickly scalable

  • Organized by business capabilities

  • Technology-agnostic

Legacy

  • Monolithic, intertwined architecture

  • Slow to scale

  • Organized around enterprise model

  • One technology stack per app

What does this mean for you?

So, if Cloud Native is so much better, should you make the move?

Consider if you will, two cars racing down a freeway at similar but not quite the same speeds.  Your car is going at 100 mph, and no matter how much you hit the gas, you cannot exceed that max speed. If your max speed, car condition, and your position in the race fulfill your ambitions, you may not have a reason to consider upgrading. If, however, you want more speed, reliability, and better chance at the top spot – you may want to consider switching.

So you decide to change vehicles, but how would you do that without coming to a halt, without injury while maintaining you position on the leaderboard?  There are significant security, cost and operational considerations to navigate – and you need a skilled, experienced partner to guide you through the change.

A study by the Cloud Native Foundation found that as of 2018, slightly over 15% of the enterprises polled use a Cloud Native approach, but by 2020 that will increase to 30%. Put another way, this means that 70% of the IT landscape will still be developing legacy applications by next year.

When you compare the features and benefits of going Cloud Native, the choice seems clear. Why, then, are enterprises slow to adopt? What are the adoption and transformation barriers?  Is it strictly a technical decision or are there other considerations? 

In the second part of this series we will look at those barriers and in future installments we will dive deeper into the cultural, organizational and technical challenges to digital transformation.