Are you ready for the Cloud?

Cloud service offerings like SaaS, PaaS, IDaaS, FaaS, IaaS, iPaaS, etc. became very popular. Gartner predicts further growth of cloud services revenue by 17% in 2019. More and more companies are looking to utilize cloud – public, private or hybrid – to become more competitive in dynamically changing world of requirements. With the cloud they can adjust their costs in a more agile way, scale more efficiently reducing the time to market of their products or services. AI, Big Data & Analytics or Blockchain are topics that companies would evaluate over the next few years, which without a cloud could become cumbersome and expensive to achieve.

Even if a project or a product that you are working on is not going to be hosted in the cloud just yet, given the fact that more and more companies are looking at cloud services, it might be worth to take into account that at some point in time your code could end up there. Below you will find a few suggestions that might help you to be better prepared for that day.

Apply patterns you already know

Separate application layers: presentation, business logic and persistence. Such a division has been in software engineering for a while now. MVC – Model – View – Controller – is an example of such a division. However, I would classify MVC as a presentation layer – a web application that utilises business logic and persistence.

Separate business logic. If your application handles various distinct use cases, maybe it’s worth to organise your code as modules per use case. You decide how many operations you put in a use case – it can be as large as authentication module, warehouse module, invoicing module, or as small as checkout operation when an order is placed online. How does it refer to transition to the cloud? If you had such a division, you could wrap each use case with http code that exposes its logic as a micro service or if it is small enough – as a function. In this case, business logic stays the same, I would argue that no code changes would be made to the core logic.

Use interfaces and dependancy injection (DI). It might sound obvious, however I have seen applications based on just classes, since it is possible to bind a class to a class with a DI framework. Interfaces allow you to abstract implementation and bring it to life in the Main component, the “ultimate detail” as described by Robert C. Martin in his book. If your configuration is injectable as well, your code can easily serve many environments – integration, test or production. Interfaces will also allow you to separate your code and ship it as JAR or DLL or any other form of code packaging.

Try different types of deployment

Spend some time to understand how does containers work and how can they enable portability of your applications. Maybe you can write and host your app in a Docker container, and move it to the cloud when the time comes. Kubernetes is gaining popularity and cloud providers are offering its hosting, hence you could deploy in any cloud to achieve High Availability (HA) or Disaster Recovery (DR) or just to compare hosting costs across multiple cloud platforms.

Watch your costs

When migrating to the cloud – or even writing for the cloud – be careful with the cost that you might generate. This advise is closely related to the next step – knowledge. Understand what is a good practice and apply it. Some tips I could give you:

• Secure access to your services and data in the cloud – breach can be expensive, both from reputation perspective as well as someone else using your resources.
• Shut it down when you do not use it! It’s very easy to start a service – and cloud is usually about paying for what you use.
• Think about how you divide your code and deploy it for scalability. If you divide too much and your architecture requires a VM per service, then it could be expensive for you to scale. Try containers in this case too.
• Use newer instances – newer processors might be more efficient when it comes to energy consumptions, hence VMs could be cheaper.
• Use load balancers that understand content routing – ALBs in AWS instead ELBs for example – so that one can support more that a single service.
• Limit number of application metrics you use. If you use external analytics tools or just AWS CloudWatch, it will cost you more if you send everything from your apps.
• Use cheap resources where you do not need high reliability. For development environments it might be beneficial to use spot instances (AWS Spot Instances or Azure Low – priority VMs).
• Think about storage – is it high or low I/O and how much do you need it.
• Take advantage of buying reserved resources. Cloud providers tend to give discounts when you pay a year or more in advance.
• Last but not least – understand how does your software work and how much resources does it need. It is easy to over-provision memory and CPU. Run performance and load tests to find out. Again, containers might save some money if services are packed on one VM.

Learn, learn, learn …

… what is out there. These days knowledge – especially in IT sector – is widely available. There are platforms that offer content for free or for a very affordable price, conferences, workshops, meetings, working groups etc.. It’s up to you to drive what you know about cloud.