The solutions developed in the pre-cloud era, may now come with many limitations to adapt to the latest trends in technology and tools. Thus, the software product companies currently either offer their solutions through a distribution model or host them in a private data center. It is not impossible to migrate to Cloud, but this presents many choices and thus many challenges. It is not just about redesigning the current software but also establishing new culture in the software development process and to be truly agile and deliver changes to market more often without compromising quality.
Today the questions is not whether to migrate to Cloud or not but should the offerings be made available in all Cloud platforms such as AWS, Azure, Google, OpenStack etc., or just one. If so, which provider to choose. Should I run my own cloud with OpenStack or should it be Cloud agnostic to be able to switch to any cloud provider with less cost. Also, would it be possible to reduce the software development and deployment costs single code base for all Cloud providers.
The Legacy Software:
- Monolithic Architecture
- Cannot be scaled horizontally
- Cannot be measured – for performance and quality
- Cannot share resource beyond infrastructure, installed in its own Infrastructure
- May or may not be available as a Server – multi-tenant
- Multiple Software versions and support
- Micro Services architecture
- Can be scaled as needed and on demand
- Can be measured for each module/service within the software to analyze performance and quality
- Can be delivered as a Service – multi-tenant
- Available in a public or private Cloud
- Opportunity to reduce overheads on supporting too many different versions
One of the primary benefits of migrating to Cloud is the reduction of cost to develop and deliver new features to market in a shorter period. For Software companies to sell their products to various industries and market segments, they have to make their offerings easily adaptable with minimum effort and time. For example, in the past, in a typical client/server 2-tier software architecture, the software was architected to be neutral to the database vendor if the target customer has a choice of database like Oracle vs SQL Server.
As a software vendor there are a few questions that you may need to answer such as, should you go in for a particular cloud provider or should the software be cloud agnostic:
- Product Roadmap: How does it affect the product roadmap; will software need to compromise certain features to become cloud agnostic
- IaaS: What are the deployment overheads that come with being cloud agnostic, security considerations
- PaaS: How do you decide between using the native PAAS offerings by the cloud provider vs Open PaaS solutions or No PaaS
- SaaS: To move the offering towards – ‘as a service’, but how? Should it be a complete rewrite?
- ROI: How to determine the return on investment on moving to Cloud and typical ongoing costs to be considered:
- Application Deployment and Testing
- Vendor Support
- Administration and Management
- Monitoring, Troubleshooting and Support
Answers depend on the software products offered and its target market or industry.
Having a strategic view in place helps smoothen the process of migration to Cloud and organizations will need to consider product life cycle, ie.,
- The life span of the product, growth expectation and how it’s going to transform in the future
- If the software can be offered as software-as-a-service in the future
- How to support the current customer base and what the migration options will be, going forward
- In a scenario where the existing customers do not want to migrate to Cloud, should there be multiple versions of the software
- If the software is currently offered as a service from a Data Center or distributed to be installed at customer’s premises
These choices also affect and shape the development and support model planned:
NO PaaS, Just IaaS:
- Typically referred as Lift/Shift, where the software is moved to a Cloud with the similar OS/VM environment.
- Requires Development team to support and maintain the environment, OS, Software, upgrades, patches etc.,
- May consider the options available from the IaaS to replace some layers in the software with the vendor’s offering such as using database as a service reduces the overhead on setting up the server, and updating and maintaining with patches etc.,
IaaS with PaaS:
- Whether Open PaaS or vendor specific PaaS services, requires re-architecting application to replace the existing integration for example Storage, Database, Caching, Queueing, notification etc.,
- The Shared responsibility model helps reduce the overheads in maintaining, supporting the services consumed from PaaS
Open PaaS, for ex:Cloud foundry
Simple: Developers focus on their code and not wiring middleware
Open: Avoid lock-in to specific cloud frameworks or service
Flexible and Scalable: Self-service, deploy and scale your applications in seconds.
Extensible architecture:to “digest” future cloud innovation. Make use of both public and private clouds without rewiring the application – protect against vendor lock-in