Resources

How to tell the difference between cloud native and cloud wrapped software

Date: June 28, 2018

Cloud computing is changing the way we all consume and interact with technology. Whether this is at home with Netflix or Amazon Alexa, or at work, with cloud-based services like Office 365 or Salesforce, or other specialist enterprise applications. In business, cloud computing is an enabler, creating strategic change in the way businesses of all sizes work with technology. In short, a real cloud-native service will make your life easier, more efficient and less expensive.

How to tell the difference & why this is important

cloud wrapped vs cloud native quoteWith all the benefits and hype that come along with the word ‘cloud’, many companies claim to have ‘cloud’ solutions but are merely hosted software services. How can you be sure that you will receive all the benefits of cloud computing, like lower cost of ownership, zero maintenance, frequent product updates, endless and elastic computing power and more?

It’s important to know the difference between real, designed for the cloud applications we call ‘cloud-native’, versus quick fix migrations of legacy code that are called ‘cloud-wrapped’. In the rush for new clients, many vendors in the financial technology market skipped the hard work of re-building their applications and simply created crude web front-ends attached to legacy application architectures. There is no easy short cut to making a real cloud-native service. It takes time and costs money, but the benefits for both clients and vendors are worth it.

Key questions you need to ask to ensure the solution is the real deal when it comes to the cloud

  1. How many versions of the solution are in production with clients?
    • One. Why? cloud-native applications are built as a collection of services on one platform that can be shared by many clients. By having only one version, the cloud service provider can ensure you receive a much better service. If each client has their own installation, it’s much more expensive to maintain for your supplier, so you end up paying more. Supporting multiple versions slows down application development and innovation. More cost for the clients to support. cloud-native applications can scale to any number of clients using the single installation and version. The more clients, the more efficient, the lower the cost. If the service is not multi-tenant, it’s not a cloud-native service and you won’t get the benefits you are looking for.
  2. Does the solution use elastic cloud computing for scalability?
    • Yes. Why should you ask this? Old software solutions work with a fixed amount of computing power. You can add servers to increase capacity, but this takes time, money and effort. Once the extra servers are added you keep them, even when they aren’t being used. An elastic cloud is where the software can order more servers for one or more hours and then stop using them when they’re no longer needed. This way, computer-processing capacity matches your workload. Let’s say you want to process all your portfolios in less than one hour every day, the service can summon up exactly the number of servers required to process your workload in that time. Thereafter, for the next 23 hours, the capacity goes back to the minimum requirement. This will reduce your IT costs tenfold. Only cloud-native solutions can do this. Traditional software cannot do this even if it is put into a cloud wrapper. To see elastic cloud scalability in action, watch this 4-minute video demonstration.
  3. How many updates are made available each year?
    • The beauty of a cloud-native solution is that the supplier can issue frequent updates to their service. We do so six times a year. What is more, all clients are updated at once – there are no special versions. One of the main issues with traditional on- premises and cloud-wrapped software is the upgrade cycle. It’s a painful and costly process. Large annual releases, involves lots of testing, versions must run in parallel, IT need to get involved and you will have to pay for internal and external consulting. Traditional software, even if it is cloud-wrapped, needs individual upgrades per installation, with one installation per client. A true cloud-native service costs nothing to upgrade and it just happens invisibly. Smaller, more manageable updates mean lower operational risk. It also means rapid and agile progress can be made within the application. It allows for the vendor to react to client and market demands.
  4. Is the solution secure? Has it been externally audited?
    • You need a big yes. It may sound counter-intuitive, but cloud-native applications are more secure than traditional on-premises software and certainly more secure than traditional software that has been wrapped in the cloud. Why is this? Application and data security is not normally part of the development process with traditional software. Security is something that is added afterwards once the application has been built. Like adding a burglar alarm to a house. With cloud-native applications, data security is designed integrally from the start, not as an afterthought. Because the application is shared between clients, you must have a secure method of managing client data. This approach results in a more secure software architecture. It’s like building a bank vault with safety deposit boxes. Making sure the application security has been externally audited to recognized standards is also important. Standards such as ISO27001, SSAE18 and the STAR certification from the Cloud Security Alliance are all good indicators of a vendor’s commitment to data security.
  5. How does the service interact with other applications, including my on-premises software?
    • This needs to be via an API. Why? You’re not going to find a software solution that can do everything you need across your business on its own. Applications need to collaborate with each other and fit into your existing processes. During your migration to the cloud, you’re going to have many critical services running on local systems. Data management is a critical part of any IT strategy. On-premises sand cloud-wrapped systems create data silos because they typically exchange data by file transfer. This causes very high levels of maintenance and complexity, leading to extremely manual processes. With data warehouses and now data lakes, a modern data strategy needs applications to participate as publishers and subscribers of data. The value in data is information you can act upon. This comes when multiple sources of data are combined with each other. To do this, you need applications that allow for native extraction of data programmatically through an API and not manual data exports in fixed file formats. The way cloud-native applications do this is via open Web APIs. These allow for seamless, programmatic access to data at any point. cloud-wrapped software is often batch driven and not dynamic. Data can only be extracted at certain times in inflexible formats that must go through additional processing to be useful anywhere else. Web APIs knit applications together so data can be joined up and made available to other applications that need it. They are the essential smart plumbing of any modern data management strategy.

Conclusion

While there are other important areas to uncover, these five questions will help you to tell the difference between cloud-native applications that come with many business benefits, and cloud-wrapped impostors that come with many of the issues of legacy on-premises software. In the end, it is less to do with the functionality of a service and more about the technology. Will the technology help you achieve your strategic goals or will it bog you down in endless complexity?

Beware of impostors, there are no shortcuts to true cloud-native software solutions.  

{{cta(‘0cffa4b7-5f11-4209-8d30-a34ac0207821’)}}