Applications in the Cloud world

Random advice if you are building applications in the Cloud. For all practical purposes, a Cloud in my opinion is the one offered by Amazon, Google, Digital Ocean, CenturyLink etc. I am not bothered with on-prem infrastructure or Hybrid models, both of which are data center technologies for all practical purposes. They are previous generation tech.

With that here is some advice. Use it at your own risk:

1. Design the application for failures

In the Cloud, things will go wrong. I will guarantee it. Whole regions will go down, servers will get rebooted, network will break. Assume the worse things and design for it.

2. Leverage Cloud specific capabilities

Don’t be afraid of leveraging cloud provider specific capabilities. For example if you are on AWS, do not be afraid to use Redshift or Kinesis. Being able to change a Cloud Service Provider is like being able to change a spouse. Both are possible, but generally not advised and really painful and you shouldn't plan your life around such plans.

3. Do not design for cross cloud portability — this is an useless attempt

Trying to design an app for portability across different cloud providers is an useless attempt. There is no value in such an exercise. It limits what your app can do and in reality, your app wouldn't be split or migrated across cloud providers.

4. Always test your application on target cloud platform, not on local infrastructure

This is super important. If you are designing an app for Cloud, test the app on that Cloud, not on your on-prem infrastructure. your test environment should match your production environment.

5. Assume rebooting the server is not an option

This is important, you can not make same assumption you make with on-prem infrastructure. It is not an option to schedule nightly reboots of the server to workaround application leaks. You have to be careful on how resources are used by your app.

6. Do not rely on app servers and frameworks designed for on-prem usage

Most of the appservers and dev frameworks that are designed for on-prem world add additional complexity that you do not need. For example, using WebSphere or WebLogic when developing for Cloud does not make lot of sense.

7. Do not worry about Cloud exit strategies — this is a futile exercise

This is something analysts and industry folks like to talk about a lot. The what if Cloud provider goes under scenario. First of all, the chances of that happening are low, unless you are using Uncle Willy and Aunt Thelma’s Cloud Service. Even if it were to happen, there will be enough companies stepping into help you transition. If a cloud provider were to go under, you have a problem on your hands, but don’t lose sleep over it or don’t constrain your app worrying about it.

8. Worry a lot about your application security — assume Cloud provider will be of no help to you — understand “shared responsibility” model

It is very likely that Cloud provider can show you a rather impressive set of security measures and compliance. It is also true that Cloud providers are lot more secure than you can ever be with your Data Center. But, the point you can not overlook is that Cloud provider is not responsible for your application security. You have to own the app side and work with cloud provider to ensure that your app is securely deployed.

9. Separate monitoring of your application from the Cloud provider

While cloud provider may provide monitoring, its important that you have an independent monitoring capabilities for your apps. It is also a good idea to have it run from a different infrastructure than the cloud provider.

10. Do not trust your Cloud provider — carefully review all your monthly expenses — either build a tool to audit the bill or have a staff member review these charges.

Cloud providers are not evil, but they are not your friends either. While they are dropping prices due to competition, their bills are becoming more complex. As your cloud usage increases, it may be worth having a staff member review these charges carefully each month. You may have instances running that are not being used and you are still paying for. You may be using storage without being aware of it.

That’s all folks.