What does transition mean and what is necessary for being successful with it?
Having an eye onto the market, architects with knowledge about how to transition existing on-premise products to the cloud may be one of the most interested and demanded skills of an architect. Pretty much every company with on-premise software now needs to think about how to offer its own products in public clouds.
Main crucial areas
Actually, there are three different dimensions in transition that are crucial:
- People
- Workplace/ environment
- Technology
To see how these three dimensions interact, let’s shortly shed some light onto what kind of on-premise software is available out there and how they fit into transition to the cloud.
On-premise software kinds
Lots of companies currently have software in place, that is mainly (or exclusive) written for being used on-premise. This covers
- Full-Client development, let’s say written in WPF, WinForms or any other language that is not immediatly cloud-enabled.
- Client-Server software is often not written in a way that allows for moving into the cloud. Going over machine borders doesn’t mean it is cloud-ready. Actually, Client-Server software has a good chance, as web-frontend based software has when it is written based on certain requirements
- Last but not least, there may be web-frontend based software that has a good chance to be moved to the cloud without too much hassle. Again, this is only possible when it is written based on necessities.
Sidenote, just to be honest: The term “cloud-ready” always sounds to me like “HD-ready” TVs. I’ve never seen any “HD-ready” TVs that are almost that brilliant than “real” HD-TVs. Being prepared but didn’t do is often a sign for not having the right requirements or the right portion of time – which can be read as money – in place. The risk is pretty high, that anyway the software needs strong reconsideration and maybe rewrite in certain areas when the plan wasn’t to run in the cloud but being prepared for the cloud.
When the plan wasn’t to run in the cloud but being prepared for the cloud, anyway the software needs strong reconsideration.
Cloud Challenges and leaks in on-premise development
Before we go into the details of the challenges in the cloud let me put a thesis:
The evolution from Full-Client development to Client-Server development is as big as the evolution from Client-Server to Cloud development
This is the technical part, so true for developers. But that’s not all. Moving to the cloud is not manageable just by developers. The whole company needs to move.
- IT Department may need to do 24/7 monitoring of machines
- Support needs to work around the clock
- Sales needs to handle and work on pay models that are quite different to what the company worked with when selling on-premise products
- Marketing needs to use different channels or needs to focus more on online/ social media
- Developer need to evolve as well as architects
I do not want to go into the details on how all the departments of a company need to evolve. Let’s focus onto the development and probably the IT department. Have a look onto the following figure. There are the main challenges that arise when moving to the cloud. You may experienced them also in Client-Server and web-based software. I doubt you did in Full Clients:
If you aren’t familiar with (all) of the topics, you may want to read the excellent explanation in Cloud Design Patterns.
Let’s get back to the thesis, that the evolution from Full Clients to Client Server is as huge as from Client Server to Cloud. As described before, if software meets a lot of criterias defined above, there should be a pretty smooth way to let this also work in public clouds. When this is the case, there have been requirements, that on-premise installed software most often does not have. Most probably, it is:
Availability and Performance/ Scalability are key driver to let software being cloud-enabled
What does Availability mean?
Availability is the proportion of time that the system is functional and working, usually measured as a percentage of uptime. It can be affected by system errors, infrastructure problems, malicious attacks, and system load. Cloud applications typically provide users with a service level agreement (SLA), so applications must be designed to maximize availability.
What does Performance and Scalability mean?
Performance is an indication of the responsiveness of a system to execute any action within a given time interval, while scalability is ability of a system either to handle increases in load without impact on performance or for the available resources to be readily increased. Cloud applications typically encounter variable workloads and peaks in activity. Predicting these, especially in a multi-tenant scenario, is almost impossible. Instead, applications should be able to scale out within limits to meet peaks in demand, and scale in when demand decreases. Scalability concerns not just compute instances, but other elements such as data storage, messaging infrastructure, and more.
Often Performance and Scalability is as important as availability. These requirements does change the overall structure of the program as software has to be designed to maximize availability. Availability and scalability have direct consequences on pretty much all topics described above:
- Data Management: If a data store, doesn’t matter if relational, NoSql, blob, elastic or whatever, is not available for a certain time, availability is influenced
- Security: If security is not considered, your service may be down by ddos attacks or being compromised by sql injection
- Performance and Scalability: If the data load is too huge and response time increase too much, some customers may experience time outs
- Resiliency: If you are in a situation where data loss happened (and you will, certainly), availability is affected negatively, when it does take a long time to recover.
- Management and Monitoring: If you do not have a proper management and monitoring system in place that allows for alerting and visualization of most crucial information, availability and performance are affected negatively without even known by you
Certainly, most of the topics above are effecting each others in some kind of way. Anyway, most on-premise software is built differently:
- Data Management: Must be handled by the customer
- Security: In terms of being reachable from the outside and care about that there are no negative side effects, is a responsibility of the customer.
- Management and Monitoring: Is not the task of the creator of the software, but the buyer of the software
- Performance and Scalability: Is due to the capacity of the machines the customer puts into charge
- Resiliency: Must be completely handled by the customer.
- Availability: Must be completely handled by the customer.
When all these topics do not need to be considered while development, it is often the case, that there are not considered at all. Of course there is Client-Server and web-based software that take care of all these topics. I do not have any survey in place, but in my recognition, most of this software will only handle above topics when there are people that have the skills or there are requirements that makes it necessary. Most probably the latter happens, when software is hosted for people (than, actually, it is not on-premise anymore) or there are needs for scalability and/ or availability.
The shift from FullClient-Everything-Is-Always-Available-And-I-Dont-Care to Client-Server is pretty tough. Considering the above topics, plus the fact that your code should really do what it needs to when being executed hundreds of time in a second, the shift from Client-Server to Cloud is probably much bigger.
Code that executes hundreds of times in a second is hard to create and maintain.
Evolve to apply Cloud Transition
What topics a development department needs to address when approaching cloud transition? How can the cloud be approached and who does it?
It doesn’t start with the code. It starts with the people and the workplace/ environment
This diagram not necessarily is true only for Cloud development. It applies to all kind of developments. Keep in mind, when moving to the cloud, you are exposed to higher risks, probably write more small section-based programs like micro services, execute code unattended, have no user interface in place and have to work with infrastructure that you don’t have under control. To make a long story short: Cloud development has high demand for skilled developers and development processes that work.
- Improve development processes: Development processes must be adopted to be small section-based. Traceable, transparent and fast. This pretty much means agile? I guess so. You’ll find another post on this very topic later on.
- Improve coding unification/ apply with code reviews: When there are “coding styles” meaning people favorite their own practices over others, team or company (best) practices, the code is going to be hard to maintain, understand and enhance. Coding needs to be unified, let people have the same perspective onto code. Also onto this topic, another post will follow.
- Improve automation: This is a tricky one. Automation is separated into two parts, infrastructure/ environment and code. For environment it is pretty easy, Continous Integration should be in place as well as Continous Delivery and probably Continous Deployment. But what means the code part? It means, each piece of software in best case can be automated. It should be irrelevant if code is controlled by Powershell or via an UI. When programming in such a way, it always offer the creator of the software to let the software being reused or integrated in any other software. Additionally, it makes code easier moveable, better understandable maintainable and enhancable. This certainly belongs to non-UI code. But even for parts in user interfaces it should be possible to act like this.
- Embrace simplicity: When complex tasks need to be worked on by developers, I’ve seen people doing complicated solutions reflexively. Due to the task is complex, the solution should also be? I don’t think so. Separate each complex topic into smaller pieces unless the pieces are easy to solve, and then reassemble. Creating simple solutions is one of the most important challenges. There is always a reason to make a mountain out of a molehill, even more when there are complex topics to be solved. Keep it simple.
- Coach & train developers: When going into the cloud, there is a strong need to coach and train developers. The topics listed above are maybe unknown and even when known, probably applied wrongly.
- Improve collaboration: Communication is always the key!
- Build trust & responsibility: People need to take responsibility to produce good or great results. People will only take responsibility when they trust. Trust peer developers, trust other departments, trust their managers. Build up trust to let people take responsibility.
- Leads to
- Improved developer skills: When all these former topics are in place and being worked on continously, developer will have improved skills.
- Improved development speed: Certainly, better skills lead to better speed in development.
- Improved quality: Better developer skills also lead to better quality. Yes, probably not immediately. But it will.
- Improved maintainability: Last but not least, it makes maintenance of software an easier task. This is a costly one, so it is crucial to have in under control.
Evolving on-premise software
Here we go for the final piece. Evolve the technology. Can on-premise software just undergo a transition and then we have cloud software? What does transition mean?
Determine Software’s current state
As stated before there are a lot of different kinds of software. When moving to the cloud, it is absolutely necessary to determine what the current status of the software is and what the objectives are. Two- or three-tier architectures are quite usual. Is the objective to move to microservices? Is the company including management and development, IT departments prepared to do that shift? Is IAAS sufficient?
Move to IAAS
It really depends on the needs of the company. If you want to allow your customers to have zero administration, meaning the customer has no installation and upgrade work to do, IAAS is probably sensible. Offering your software in the cloud anyway sounds good these days. Recognition of customers if software runs hosted or is SAAS may not be relevant.
Installing on-premise software on virtual machines may be tricky. Some of the cloud challenges will hit you immediately:
- Availability: Is the system alive and running? Does the customer know, when upgrades are applied? How long is the software meant to be available?
- Data Management: What is your data backup strategy? What happens, when data is gone? What happens, when the customer deleted necessary data and you are in charge?
- Security: How to secure your virtual machines and the software that is probably now publicly available?
- Performance and Scalability: How to scale the system? (most probably, there is vertial scalability, horizontally scalability depends on the so
- Resiliency: How to recover when the virtual machine is not available anymore? How long does it take until your customers can work again?
- Management and Monitoring: How to recognize that a customer can not work anymore? What actions can be applied to change this situation?
Actually these are almost technical issues. You may experience more:
- How to automate installation/ setup of a customer machine?
- How to automate upgrades?
- Is the data between customers strongly separated? (Customer that see data of others may not be the best advertisement)
- How costly is the infrastructure?
- How cheap is the competition?
- What effort does it mean to develop for on-premise and IAAS?
- What effort does it mean to maintain tens or hundreds of virtual machines and how to do it?
These questions need to be answered before moving. Doing so will minimize surprises and trouble.
Move to SAAS
What are the requirements or SAAS from business point of view (no means to be complete)?
- Software that is easy and intuitive to understand and use
- Software where the company not necessarily needs sales department and consultancy.
- Software that can be paid and used immediately
- Software that can be enhanced immediately
- Software that can be easily deployed behind the scenes, meaning bugfixes, hotfixes, new features can be added adhoc
- Software that scales on demand
- Software that is secure
To be honest this all comes to a price. Actually most of the on-premise software will not meet the requirements. And transition can take longer than reimplementation. Most probably it will take longer.
It is great to buy an old house and renovate it. It takes time. A lot of money. And there are compromises that can’t be changed at all. So it is with software.
The actual challenge is to double check the software and understand the potential if it can be moved to a microservices architecture or anything else that is appropriate for the software in question.
- Keep in mind that microservices rely on strong infrastructure like messaging, cloud storages.
- Remember that in public cloud, pretty much everything is based on connectivity. Your code should be able to handle time outs gracefully and retry
Containerization
Last but not least, let put this point. You may have a step between IAAS and SAAS. Containerization, most popular right now with Docker, is may be the first step after bringing software to IAAS. It solves a lot of issues:
- Compatibility and Maintainability
- Environment Standardization and Version Control
- Simplicity and Faster Configurations
- Rapid Deployment
- Continuous Deployment and Testing
- Multi-Cloud Platforms
- Isolation
- Security
If you are looking for multi tenancy support of your client-server product, this can keep IAAS costs low while providing Cloud services to your customers. Actually giving yourself time to set up SAAS from scratch. Actually I believe, for most of the software out there, this unluckily is true:
In the majority of the cases, SAAS means rewrite
Keep in mind, when doing transition, it doesn’t necessarily mean code. It means the whole company.
