Archive for December, 2016

Is your apps “Cloud Ready”?

December 11, 2016

It was mainframes before the 90s, then came the client-server architecture and the web followed that in 2000.  The web architecture is somewhat similar to the mainframe architecture. I started my career in client-server, went to the web and now I’m in cloud. The technology departments in the corporate world and the IT services firms assisted in the migration from mainframe to client-server to the web. One need to change the mind-set while designing apps for specific technology platform. It will be easy to understand if you look at each of these technology framework as a genre. The current cloud architecture actually resembles the client-server architecture to a great extent. These days, the apps are feature rich with majority of the processing happening on the server side while still rendering logic on the client side (AngularJS website, apps on your phone etc.)

The are multiple cloud offerings, I mean IaaS, PaaS and of course there are many vendors Amazon, Microsoft, Google, Rackspace, Openstack and the list keeps going. You can have private cloud, public cloud and hybrid cloud. Now, everything you need is provided and is available as an app. The concept called SaaS which started in early 2000s with the advent of websites.

Let’s talk about migrating your applications that are currently living in your data centers or co-hosted or on your own premises. The easiest way is to follow the IaaS path wherein the physical servers are replaced with the VMs in the cloud. I’m saying this as easy because if your servers are currently in a data center you are any way remotely connecting to them from your personal device (PC, mac, Chrome – whatever), it doesn’t matter whether the remote server is in your DC or in Amazon or Microsoft DC. Apart from this, your applications doesn’t need to undergo any change, pretty much. However, this will not let you take advantage of “the cloud” offerings.

The second approach is to build your apps and make it available as SaaS by using the PaaS. This is where you will reap the benefits of the cloud architecture. Wait, you will hear from everyone, oh you are going to get locked up with a vendor! This is true if you were asking me about this even three years ago. Now, the cloud offerings have matured and one approach you can follow is to use containers such as Docker.

Let us take a hypothetical app where you receive data from your various vendors, the app need to load the data, notify vendors / your IT / business on failures, notify customers of the changes and that the latest information is available on the website for everyone to access. In such an app, in the current world (hosted in a physical or virtual server in your DC), you can have your own FTP server to pull the data from vendors and store the files in the file system of your server; with SMTP service running in your server to send the notification emails; any failure files can be moved to an error folder and error logs written to a log file in the log folder; Once the data is valid, you can update your database which forms a separate cluster in your network. If such an app/ website need to be hosted on the cloud, it need to be made “cloud ready”. What does it mean by “cloud ready”. Some of the salient features of a “cloud ready” apps are being machine agnostic, self-aware, secure and more. We will see the top ones here.

  1. Machine agnostic. – some examples
    • No file system – store files on AWS S3 / Azure cloud storage/ drop box [if you really want one, try the AWS EFS, it’s a network file system and you can use like NAS]. If you have a server, you will have a file system, but you should avoid them as it will have issues when you scale up and scale down. In Azure, the local C drive is temporary and you lose all data on it on reboot (other than the OS).
    • No local ftp / SMTP – use other mechanisms or 3rd party [FTP is a serious security issue], use AWS SES or other providers for email.
  2. Self Aware
    • Apps should be service oriented and the service endpoints are fetched from the application config files.
  3. Secure
    • Secure communications – Use SSL and encrypt all communications especially if you are in a regulated industry (eg:HIPAA). if you are app is calling other allied service end-points pass encrypted data and follow authentication and authorization policies. This is something often discounted when you are writing apps for your own DC though it’s a recommended practice.
    • Encrypt Data @ Rest- Don’t keep PII (Personal Identifiable Information) but if you need, you should encrypt that stored data. This includes any document / form data that you collect, create.
    • if you let users upload to your S3, please use proper authorization policy and move them out into a secured bucket ASAP.

In addition to these, there are more and my intention is to bring your attention to this and not to write a thesis. You are always welcome to write to me, if you want to discuss more.

Getting your apps to the cloud opens up possibilities,  more tools & technology at your disposal. You can easily start notifying your clients through SMS (trulio), you can cache the data if you are using GCE, you can use Firebase / AWS cahching to synchronize data and provide a seamless experience irrespective of the device form factor. Ultimately, your application will be device agnostic and your apps can follow your user from phone to PC to TV.

These thoughts are not just for migrating, you need to keep this in mind for newer applications you are building. Feel free to drop me a line if you need help migrating legacy apps to the cloud.