An increasing number of organisations have moved, or are planning to move, to cloud-based hosting and are developing their applications to run in the cloud. However, once it's decided that your next application is going to run in the cloud, there are still a lot of architectural choices ahead of you. Besides obvious benefits like cost reduction, scalability and easier administration, cloud environments bring their own disadvantages and potential risks. In this blog, I'll share with you some tips on how to take care of the most important disadvantages and risks when you decide to build your applications for the cloud.
We will look at the various options for running your application:
- In an existing application container (such as a Payara Server or Spring Boot)
- On an Infrastructure as a Service (IaaS) platform
- Using a cloud service to automatically provision the necessary runtime, and Function as a service (FaaS) platforms, often referred to as Serverless
Each of these options introduces greater benefits and flexibility than previous options. But it also comes at a cost, usually by limiting architectural choices, reducing control over the infrastructure and often introducing greater vendor lock-in to a specific cloud provider.
The choice that you make for your application may be one of these, or a hybrid of any of them, but understanding the options is key to being able to make the right decision.
Tip 1: Assess Each Cloud Option
To make the best choice from available cloud options, you should understand the main benefits, risks and disadvantages of each option.
Infrastructure as a Service
Infrastructure as a Service (IaaS) platforms supply you with "compute nodes" - virtual machines on which you install your runtime of choice. This approach allows you to make the most of your existing skills within your development and operations teams, while avoiding running your own data centre and maintaining networks. The responsiveness of cloud provisioning allows you to develop a truly cloud native application that scales up and down with demand, makes use of cloud storage services, and relies on cloud networking, without having to learn new languages or frameworks.
- Re-use existing skills and framework knowledge
- Scale with demand
- Don't need detailed hardware and networking knowledge
- Can use the frameworks and libraries that you want
- Need to maintain system administration skills
- Some resources always provisioned even if not needed
- Need to architect for performance, resilience and failover
- No automatic cloud container provisioning
Payara Server and Payara Micro work well with this approach as they provide flexible options for how to configure networking between multiple server instances to suite any cloud topology. Besides differences in networking, applications can run on Payara Platform in IaaS in the same way as you are used to.
Automatic Cloud Provisioning Service
The second approach to consider is using a service with automatic provisioning, such as Amazon Elastic Beanstalk or services based on Kubernetes. With these services, you upload your application to the cloud, and the service provisions appropriate infrastructure in a way that provides load balancing, scaling, and failover for you. This, in terms of automating best practices, ensures that your application meets your non-functional requirements. It may limit you to working with a certain set of frameworks and containers. However, most of these services support running applications packaged as Docker containers, which allows using any frameworks and dependencies of your choice.
- Don't need as detailed architectural skills
- Provision the infrastructure you need
- Don't need as many system administration skills
- Don't need detailed hardware skills
- Resilience and failover are automatically provided
- Often limits framework choices or packaging format (Docker)
- Still some resources provisioned even if not needed
Most cloud services don't support Java EE or Payara Platform directly. However, they support running Docker containers. Both Payara Server and Payara Micro are fine-tuned for running in Docker. You can easily use the officially supported Docker images which are preconfigured to get the most out of Payara Platform right out of the box.
- Taking Payara To The Cloud
- Clustering Payara Server in Docker
- Scaling Payara Micro Applications with Kubernetes
Function as a Service (FaaS)
The third approach is to use an FaaS architecture, such as Amazon AWS Lambda. For this approach, you write functions which contain only your business logic and upload them to the cloud, and then pay per function invocation. This can work out incredibly cheap, as you don’t need to over provision storage or compute resources for your application. On the other hand, you leave all the control over the execution of your application to the platform. You also need to be aware that this approach limits you to writing your application in specific languages and can only make use of certain APIs and frameworks. FaaS architectures also tend to be event driven, which requires a very different architecture to the Object-Oriented approaches that are common today.
- Very cost efficient
- Resilience and failover are handled by the cloud
- No operating system administration knowledge required
- Only pay for execution - no risk of over provisioning
- No hardware skills needed
- Limited in what APIs and libraries you have access to
- Event driven architecture needs different design patterns
- Very little control over the execution of your application
- Difficult to test and debug applications
Building your application for FaaS severely limits how you can use Payara Platform. It's possible to run embedded Payara Micro from a function but it's not straightforward and it's beneficial only for very complex functions. The best usage of Payara Platform with FaaS is to use FaaS functions only for specific application components which benefit from FaaS most while building other components as Docker containers with Payara Platform and run them on an automatic provisioning service.
Tip 2: Carefully Evaluate Migration and Cloud Maintenance Costs
In many cases, moving applications to the cloud will result in reduced operational costs. Each cloud option in the order listed above offers less and less resource usage, simpler administration and greater abstraction over the infrastructure. Even to the point when your code is still running on a FaaS platform, served by an infrastructure you don't have any control over. On the other hand, you should also evaluate added costs, which are very often subtle and not easy to estimate.
The bigger the abstraction, the longer it takes to master the platform maintenance and associated tools. Especially if something goes wrong or the application needs to be tuned later. In order to effectively resolve production incidents and improve performance, you need to understand how the cloud environment works. The more you let the environment do for you the less control you have and the more complicated is to understand and resolve any problems caused by the infrastructure or misconfiguration. Some cloud options even leave details intentionally undocumented or subject to change without notice in order to improve resource usage and overall platform efficiency. All of this has a great impact on maintenance costs and even business costs. You should carefully evaluate whether the expected cost reduction is worth all these risks and choose the cloud option which offers the best balance between savings and risks for your application.
Another thing to consider is the cost of added scalability. Some cloud options offer automatic infrastructure provisioning and almost infinite scaling of resources to meet your non-functional requirements. However, scaling resources up to meet an increasing demand comes at an additional cost. And this cost may not always be compensated by any business benefits. It's important to identify when paying for extra resources to improve performance isn't going to add any business value and implement reasonable scaling limits.
For existing applications, you also need to factor in the costs of the migration of both the application and its data. While migrating to a cloud option that offers greater theoretical benefits might be tempting, the overall migration and maintenance cost of a legacy application may be bigger than the benefits. Very often the ratio of costs and benefits is better when migrating to a cloud option which is more similar to the current option. Sometimes even moving applications as they are to an IaaS platform brings more benefits on its own than any other cloud option could add on top of it.
Applications running on Payara Platform can benefit from many cloud optimizations and flexible configuration options that are already present in Payara Server and Payara Micro. On top of that, both Payara Platform runtimes provide a lot of monitoring services out of the box, thus making it easy to understand what's going on even in the cloud environment. Distributed tracing of requests between services is remarkably helpful to understand the communication flow between multiple services managed by the cloud.
Tip 3: Choose the Right Cloud Provider for Your Cloud-Native Applications
Even if you understand all the cloud options and how they may impact your maintenance costs, you still need to consider differences between various cloud providers. There are many aspects that may be important for you to consider, including:
- Wide range of cloud-native services. For example, Amazon Web Services is the biggest cloud provider to date, offers more than 100 distinct cloud services, including distributed databases, brokers, routers, and monitoring services.
- How well are cloud services integrated and easy to maintain? A vast array of options isn't always what matters most. A sufficient number of well integrated services can save you a lot of maintenance and provisioning costs.
- The number of datacenters, their location and connection quality. For applications exposed to extremely large number of requests of processing large datasets, high network speed and low latency are very important. Some big cloud providers may not offer a data center which is close enough to your customers. Other cloud providers may not have many datacenters but may have one which can serve your customers very fast.
- Price. In theory, some cloud options should consume fewer resources and be cheaper than other options. But pricing of services at concrete cloud providers matters, too. You should always check what the estimated price would be when you consider multiple providers. Sometimes a specific FaaS platform can end up being more expensive in your case than another non-FaaS cloud option at another cloud provider, which is most often easier to develop for and manage.
Payara Platform is designed to run on wide range of cloud services by various cloud providers. We test Payara Platform with a growing number of cloud providers and cooperate with the cloud providers to provide guides and examples on how to use Payara Server and Payara Micro effectively with them.
- AWS Native Discovery with Payara Micro
- Using Payara Datagrid with a load balancer on Microsoft Azure (video)
- Payara Clustering: Running Highly-Available Applications in the Jelastic Cloud
- Payara Micro on OpenShift
Tip 4: Consider Security
Public cloud platforms offer less security than standard on-premises environments. This could pose a challenge for companies with complex security requirements. A solution is to opt for a private cloud, which runs your cloud environment on a dedicated hardware, either at a cloud provider or your own hardware. However, this makes your company responsible for the cost and accountability of managing the private cloud.
Another option is to combine the benefits of private and public cloud into a hybrid cloud. In this setup, sensitive application components would be deployed into a more secure private cloud environment while less sensitive components would be deployed in a public cloud, allowing them to benefit from virtually infinite resources available in the cloud. Hybrid clouds are more complicated to set up initially to enforce required security regulations, but once set up are more flexible and cheaper to maintain than pure, private clouds.
Some cloud providers offer a private cloud option and also allow to connect it to their public cloud to get all benefits of a hybrid cloud solution. Payara Platform runs on private and hybrid clouds in the same way as on public clouds. Furthermore, with the commercial Payara Scales solution, which uses Hazelcast IMDG Enterprise, you can create a cluster across your private and public clouds that scales efficiently using WAN replication and allows for securing cluster communication using SSL/TLS.
Choosing the Right Fit for Your Cloud-Native Application
As you can see, there are many approaches for building a cloud-native application, and they can all be combined, allowing different ones being used to deliver the different parts of your application. If you are still unsure, just remember that ultimately the right choice is the one that makes the most sense for you as an organisation, and that this will probably vary from application to application. Personally, I think there is a lot to be said for serverless architectures, but they do have some quite significant disadvantages that need to be considered. For example, their biggest benefit, cost efficiency, is entirely dependent on vendor pricing and how it changes in the future.
Whilst we have not covered everything, these approaches are a good place to start. Hopefully this blog has helped to encourage you to consider all the options and that, rather than just continuing to write software the same way you do now, you will be confident considering deploying it onto the cloud.
Ready to Get Started with the Payara Platform?
Considering a Migration to the Payara Platform?
Here's how to do it: