Mistakes Most People Make When Developing Cloud Native Apps

Businesses are no longer scared to move to the Cloud amid security concerns. Cloud vendors are reinforcing the security of their networks and appliances. For the tech teams, cloud is something they would love to experience with. The term “cloud” is an envelope for a hybrid world;

• a network engineer sees the cloud in terms of infrastructure as a service (IaaS)
• a software engineer or a database admin the cloud is seen as platform as a service (PaaS)
• to an end user such as marketer, the cloud is a software as a service (SaaS)
• the architect has to take a more holistic view of the cloud

This article will focus on the software engineer view of the cloud but not only as PaaS but also IaaS.

The Infrastructure

Developers do not always think about the infrastructure their software will be running on. Developing for the cloud requires developer to be more attentive to details;

• what are the environments specs?
• Any network requirements such as firewall ports required for inbound/ outbound communications?
• What software environment is required, i.e.Java RE versions
• Tomcat/ Application Servers
• How do we scale up/down on application load?

Those are basics questions the development team should ask themselves. Is it the role of the lead developer to ensure the environment meets their requirements or should these requirements be taken care of by a more strategic team such as the Architects? Infrastructure as a Service works the same way as having your own dedicated environment. You have to take on the headache or configuring and maintaining the various environment and how they integrate together. It is easy to spin off new virtual boxes to host your database and set-up the networking to make it visible to the rest of the appliances. Another question spurt to mind;

• Does your database need to scale?

IaaS is definitely the most flexible when comparing it to PaaS services. The developers have more control over it and can customise it as they see fit. But as a great mind once said:

“with great power comes great responsibility”

Benjamin “Uncle Ben” Parker.

IaaS can be quickly become complex and daunting even for a seasoned cloud professional. A major mistake made by development team is the “tunnel vision” approach to writing software without considering the infrastructure. The industry has evolved and new tools have been made available to help such as Kubernetes and Docker. I believe the time of the “singleton” developer is numbered and the rise of the DevOps is upon us. The line will blur and developers will be expected to understand the environment their code will be pushed into and how to take control of it.

Platform as a Service

The simpler definition of PaaS would be: an environment which is maintained entirely by a third-party and all you do is deploy to your code to. Well, the reality is that you might have to do a little bit of customization by very light-weight in comparison to a fully fledge IaaS environment. Based on my experience working on the following PaaS environments: OpenShift, Amazon Beanstalk, Google AppEngine and Heroku, those environment removes some of the complexity involved in deploying your application to the cloud. To put it in context, let’s say we were working on a greenfield project with the following simple requirements:

• Provide a web user interface for people to create new cases
• Cases will have workflows attached to track progress
• Documents can be uploaded against workflow
• Etc…

The argument sake, our programming language of choice is Java. Based on the above requirements, we can deduct that

• we will need a Java application server
• a database to store users/cases/etc…
• a file store to store the cases’ documents
• a workflow engine
• and a public facing IP address (maybe a load balancer and DNS server)
• and YES the application has to be highly available

if your team is stretched in your small organisation, last thing you want to worry about is your deployment environment. A PaaS solution would be a match made a in “heaven”, no pun intended. We still have a recurring problem of who makes the decision on what to use: the lead developer or the more strategic team of Architects? As an architect, off course I would say we design the platform therefore we also make the decision on the PaaS architecture. Let’s examine the aforementioned requirements and discuss how we could achieve it with Amazon AWS PaaS offering:

• Amazon Beanstalk: depending on your preferred language, in our case Java, beanstalk will be an Apache Tomcat environment where we will deploy our WAR files. There are some intricacies to consider when writing code for environments such as Beanstalk; sharing of data to centralised as opposed to using static variable, do object in memory / cache need to be available to all instances? Also, Beanstalk might be running on Apache Tomcat for Java but it does not mean that you have the same flexibility as running your own local servlet container. Almost think about your code as being serverless, as in no state is kept on the Tomcat which is harder to accomplish, ie. What about application sessions?
• Amazon RDS: applications need to store data somewhere and our application is no exception. RDS act as a service proxy to relational databases. It worries about its configuration, scalability and availability. Behind the scenes, RDS provides various databases such MySQL, Postgres and MS SQL. We can create an RDS instance and use JPA in our code to connect.
• Amazon S3: S3 would be used to store documents which are uploaded through our application. S3 is provided as PaaS and therefore we do not have to worry about its maintenance and scalability. We only have to make sure that our application can communicate with the S3 bucket
• Amazon Simple Workflow Service: SWF is Amazon workflow as a service which third-party application can integrate for workflow functionalities.
• Amazon Elastic Load Balancer and IP: ELB provided by Amazon removes the headache of having to configure and maintain your own load balancer to provide a highly available application

Developers have to remember that PaaS is not suitable for all applications. A simple example where PaaS would not be recommended is when you require to heavily customise your Tomcat/ application server or access to OS environment, for existing application where it would require a rewrite. For greenfield applications, PaaS might be an option and projects could be architected accordingly.

Hybrid Environment

A hybrid cloud environment would see a mixture of IaaS and PaaS for the deployment of your applications. The development team could spinoff boxes which will be configured for hosting the application code on Tomcat, while the database could be hosted in RDS. The high availability, ELB and a DNS server could be utilised. The hybrid environment could provide best of both worlds when considering a cloud architecture for your cloud native app.

Conclusion

Developing cloud native apps bring their own complexities. Many companies put everything on the lead developer plate which is an expensive mistake. Cloud architects evaluate the offerings and can map the requirements accordingly. Also, it is important to understand the difference between a IaaS and PaaS when deciding where applications should be deployed. Based on experience, most development teams will take a hybrid approach to architecture and deployment.

printed with permission from Kiktronik Limited