Cloud Source
Showing results for 
Search instead for 
Do you mean 

6 key decisions before developing an app for the cloud

on ‎02-05-2014 11:49 PM

Appdev.jpgIn my last blog posts I discussed several times how to take existing applications to the cloud, but that’s not the only scenario. When going to the cloud, some companies decide to start from scratch and develop new applications. What are the key elements they need to take into account? Let’s review those for a moment.


Before designing and developing the application, one question has to be asked. What services will this application deliver? Indeed, as I already mention several times, cloud computing is all about services, the delivery of a given functionality to the end-user. Obviously, those services are delivered by applications and one application may deliver multiple of those. Some will deliver their functionality to the end-user, while others will be used by other services and return the appropriate information.


To depict that, I typically end-up creating a Visio chart where I show the link between the different services, so I get a better understanding of the scope of the application and how it supports the business processes of the enterprise.


Once we have that understanding, we now need to look at how we develop that application and I would suggest we need to look at 5 important points.


First: Define the target cloud

The first question to ask is on what cloud the application should be hosted.  The criteria I discussed in a previous blog post, titled “In what cloud do I host my application?” are equally valid for new applications.

Obviously some of the questions related to the operating system and middleware versions are less relevant, but the basics remain. Is your application core or context, does it have geographical constraints (Privacy issues, export regulations etc.), does it need to link to existing data sources and what are the latencies required etc. are still relevant. Actually starting by asking yourself those questions allows you to keep in mind what you have to look at when developing the application.


Let me take an example. If you want to put an application in a public or managed cloud, and that application requires access to a data source that is maintained in your internal legacy environment, make sure that, when developing the application, you ensure none of the customer facing services are delayed by the access to the data, so you become independent of the potential variability in latency.


Second: Mobile Enable

The second question is obviously related to how the user will access the application and its services. In the current environment where we expect to be connected anyplace anytime, thinking support of multiple platforms is key. The question is now, which platforms will be supported. Can the service be accessed comfortably from a smartphone, or does it require a larger footprint, hinting towards limiting it to tablets? Browser and PC access are no brainers, but it’s the tablet/smartphone area that needs to be defined. Keep your BYOD strategy in mind, but at the same time, realize this strategy may change over the lifetime of the application. Even if initially you do not set-up support for mobile applications, build the concept into your design so, when required, you can quickly take action.


The second aspect to look at here is what you do in the mobile app and what you do back in the cloud. Here, one key question has to be asked, and that is related to the security of the device. What information are you willing to transit to the mobile device and how will you secure that information while it is transiting on the device.

Techniques such as HP AnyWhere exist. They will on the one end manage the secure distribution of your applications and on the other run those in a separate, secure, container. But the question remain as you need to assess the security required for the application and its data and compare it with the apparent security provided by the device.


Third: How many concurrent users will you have?

It’s a fair question, but in many situation it is one you cannot answer when starting the design of your application. What you want is that, regardless of the amount of concurrent users you have, your user facing services respond quickly, delivering a powerful user experience.

This means that those services may have to be capable of running multiple parallel instances. You may call upon a load balancer to route the requests to the appropriate instance. Build that in into your design. Look at whether the back-end services also need multiple instances and use message queues to link and trigger activities between the services.


Fourth: What about the data?

The application will use data. Some of that data will be pre-existing data sources, some will be data created by the application itself. Where is that data located and what data repositories are used?

Access to the pre-existing data sources is a special case of integration we will be discussing in the next point. So let’s focus on the data generated by the application itself. What is the sensitivity of that data and can it reside in the same environment than the one the application runs into. Now, remember, running an application is a transient operation, data is permanent. So, here again, considerations about security, data ownership, legal requirements etc. have to be addressed.


If all of that is OK, your next question will be what data structures you will use. In most cases it will be a relational database. Should you go for one of the traditional databases you have in your legacy environment or one of the new structures becoming available in cloud environments. One option is to use a database as a service, which frees you up of having to manage your database yourself. However, it poses the question on the ownership of the data and how you get your data back if you decide to leave that cloud environment. The second question is whether you use an SQL or noSQL database. All depends the amount of data the application will generate as noSQL databases are better suited for heavy read/write loads.


Fifth: Look at integration

It’s very seldom you develop a new application that has no integration with the existing environment. You may need access to existing data sources, or you may even have to call upon existing functionality. For example if my new application has to provide the status of an order, there is a fair chance I’ll need to trigger an order status look-up in the existing ERP environment. Web enabling those back-end services facilitates the job. That is why I would strongly recommend you to go that route. Web-enable queries in databases and expose legacy application functionality as web services. It will provide you a clear separation between the legacy and the new environment. And if one day you decide to replace the legacy environment, as long as you expose the service in the same way, you do not need to change your application. For the data you may also want to look at the implementation of an enterprise bus to facilitate data access.


Sixth: Go Agile

Once you have addressed the first two points, you know on what cloud your application is supposed to run, what it’s front-end will be and what functionality is done in the front-end and the back-end. Now it’s time to start developing the application. In many cases, such cloud based developments are something new, so make sure you build into your development cycle the possibility to adapt what you’re doing to what you learn. And that is where agile development really adds value.


Did you notice that your mobile applications are updated on a regular basis? Every time they’re updated, some new functionality becomes available. Why not do that for the application we want to develop. This will allow us to get feedback from our users and improve the application and its services along the way. But what do we need to make this happen. Fundamentally two things:


  • Automate the testing of the applications at every step in the development process, so developers can check in their code every workday and have it tested overnight, speeding up the development process.
  •  Continuous deployment, automate the integration of the developed modules and have them automatically installed in the appropriate environment for each step of the development, QA, staging and operation phase.


Combining those two allow developers to focus on their core responsibility, developing application modules, while the new functionality is tested quickly and rolled out in production. By closing the loop first with test users and later with the overall user community, the application can be adapted and improved very quickly.

Not only does this provides you the opportunity to deliver a better application, but also to adapt it every time the business requires a change.



Six key questions to look at. It may sound cumbersome. When you embark on your first application you may want to take the time to make the appropriate decisions. This will be time well spent as it will help you set-up a framework for the development of your future applications. Believe me, when running a half marathon, start slowly, you’ll get there faster.

About the Author


on ‎02-13-2014 11:39 AM



Good Blog. And after reading it I have reached the conclusion that this diligence is no different than what you would do for any new app development, cloud or othewise.


I do have a differing opinion on the use of NoSQL for heavy database read/writes. I agree for the reads, but since NoSQL databases lack ACID properties, they are definitley not suitable for database write workloads. Now, there is a huge amount of venture investment this year into adding ACID properties to NoSQL databases, and it is a matter of time, before they challenge relational databases, but that would come at the cost of performance of read operations (Welcome to the challenges of relational database world).


Another area to pay attention to is the SLAs that this app would need to meet. You touch upon performance with number of concurrent users. Need to pay attention to response time, throughput, cost of transaction as well. And what about availability of this service that the app would provide?


Data privacy - you covered it well. I would add data scrubbing to this list. What happens to my data when my app instance concludes and I let go of the compute instance?


Keep these Blogs coming. Thank you...Ajaya

Ajaya Gummadi

NonStop Data & Cloud Product Manager

Hewlett-Packard Company

+1 408 691 2908

on ‎02-13-2014 11:48 AM

Thanks for commenting, Ajaya. You are actually making some very good points.

  • You're correct regarding the ACID nature required in the write space on databases, at least for some types of data. So, here again, it's not one size fits all. Your insights are correct and add an additional element of decision making.
  • Regarding concurrent users, responsiveness/response time was actually in the back of my mind. I should have made it explicit, you are correct.
  • Again, data scrubbing or digital schredding is a key element. It is part of what we do in our clouds, that's probably the reason why I forgot to talk about it.

Thanks for highlighting these points.

on ‎02-24-2014 09:09 PM

Nice View of Cloud Application, it probably depends upon business type, which best to choose. And other side why not to try to use hybrid for the same way solutions.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all