Payara and PaaS with Platform.sh
Payara and PaaS with Platform.sh
This article discusses how to create your first REST project with Payara Micro, and then move that project to Platform.sh using the Maven Archetype.
Join the DZone community and get the full member experience.Join For Free
What’s the Cloud?
Software is everywhere. No matter where you look, there is software running. In human history, we’ve seen the number of machines/software increase with time, from one machine shared by a bunch of people, to a single person using thousands of software programs. Now, we can see software interacting with other software, such as when you buy a flight ticket: a system sends an email, another reads it and fires an event into your calendar. This new approach opens more business perspectives and opportunities for everybody, including machine learning. Make no mistake, Skynet is coming soon.
The Birth of Agile
It’s not just the amount of software that has increased, but also the number of interactions in a program itself. More users, more requirements, more feedback. It doesn’t make sense to wait years to release a product, the time-to-market and the user feedback are vital to drive the product in the right direction. That’s why in 2001, a small group of people, tired of the traditional approach to managing software development projects, designed the Agile Manifesto, which gave birth to the Agile methodology.
Agile is a process that helps teams provide quick and unpredictable responses to the feedback they receive on their project. It creates opportunities to assess a project’s direction during the development cycle. Organizations evaluate the project in regular meetings called sprints or iterations. In a more technical aspect aligning with Agile, the Domain-Driven Design (DDD) approach to developing software for complex needs deeply connects the implementation to an evolving model of the core business concepts. Techniques such as Ubiquitous Language are used to having the code closer to the business, decreasing the barrier between the developer and the user, and therefore, having more interactions than with Agile development.
More and more companies understand that all companies are software companies. As a result of relying heavily on software, companies frequently need to hire software developers. The question of how to handle several people working on just one project then arises. To solve this modern question, we can look at an ancient Roman military strategy: divide and conquer. Yes, divide a highly complex issue into small blocks of problems, split the team into small groups and divide the monolithic project into smaller ones. The Microservice architectural style is an approach to developing a single application into a suite of small services so that, for example, instead of an e-commerce company working with just one code-base and one implementation, it can split the teams/code in financial, product stock, marketing and so on. One thing to point out, the DDD context is still there. Indeed, it works alongside the approach for how to create useful services based on some of its bounded concepts; we’re not discarding or deprecating that notion, but aggregating it into microservices.
Microservices, beyond making the team more Agile, also bring several advantages such as independent scaling-up and releasing discrete services. However, it carries more twists in the operations side. Finalized code is not enough if it does not go to production. Thus the operations must follow the development team to release what the system needs to deploy every day. This is why: DevOps is a set of software development practices that combine software development (Dev) and information-technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.
With both development and operations teams integrated and working together with the DevOps methodology, we're ready to handle software and operations. But how about hardware? Integrating the team means that equipment does not exist. What happens when a team needs more computer power? Does it make sense for somebody to go buy a new server? It isn't fast enough. In the global market and with the milliseconds battle to get less response time, a closer server to the client means less throughput time, but how do we buy/keep servers in several continents?
With cloud computing that is available on-demand for computer system resources, especially data storage and computing power, without direct active management by the user, Cloud computing means: we don't care about the hardware itself. These services are broadly divided into three categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).
These categories bring a new business concept to the market. Furthermore, each service brings new facilities, mainly fast delivery.
There is a fantastic article that explains the benefits of cloud computing with the most popular and delicious food in the world as an example. That's right, pizza!
Benefits of IaaS
No need to invest in your own hardware
Infrastructure scales on demand to support dynamic workloads
Benefits of PaaS:
Develop applications and get to market faster
Reduce complexity with middleware as a service
Benefits of SaaS:
Apps and data are accessible from any connected computer.
No data is lost if your laptop breaks because the information is in the cloud.
A software project that has fast delivery as the best strategic approach. A quick release brings several benefits, such as receiving feedback, fixing bugs, and mainly driving the product in the right direction based on the user needs. That’s why several methodologies/technologies such as Agile, microservices, DevOps, and cloud were born. Nowadays, it is hard to think of waiting one year to release a project, running the risk of missing the right timing. The Java community has decided to push a release every six months, and Jakarta EE seeks the same path. Platform.sh has the goal of making it easier to move your project to cloud-computing, allowing you to deploy anywhere and anytime, including on a sunny Friday.
What’s Cloud Native?
Cloud computing has brought many methodologies and techniques that have revolutionized both the business and technical worlds. Among the terms that came up was cloud-native. To meet and cover these expectations in the Java universe, Jakarta EE emerged.
Like any new concept, there are several concepts with the same name; if you read books or articles about cloud-native, you may not find consensus about it. For example:
Cloud-native is an approach to building and running applications that exploits the advantages of the cloud computing model. —Pivotal
Cloud-native is a different way of thinking and reasoning about software systems. It embodies the following concepts: powered by disposable infrastructure, composed of bounded, scales globally, embraces disposable architecture. — Architecting Cloud Native Applications
In general usage, “cloud-native” is an approach to building and running applications that exploits the advantages of the cloud-computing delivery model. “Cloud-native” is about how applications are created and deployed, not where. — InfoWorld
An approach that I enjoy is that I use based on those books and articles is:
A set of good practices to optimize an application in the cloud through:
In a mutual consensus around the definitions from several articles, we can say that cloud-native is a term used to describe container-based environments. So cloud-native isn't related to specific programming languages or frameworks or even to a cloud provider company, but to containers.
What Are Cloud-Native Best Practices?
When we start to learn a new concept, we usually run to read about best practices to avoid mistakes and any code smell. With Object-Oriented Programming (OOP), we have the design patterns from the gang of four, in Java we have Effective Java, and when talking about architecture, we have both Clean Code and Clean Architecture. So the question is: what are the best practices for cloud-native?
As far as we know, there aren't best practices related specifically to cloud-native. But since the cloud is close to Agile methodology, there are several practices we can leverage to have a healthy, pain-free application:
- Codebase: One codebase tracked in revision control, many deploys
- Dependencies: Explicitly declare and isolate dependencies
- Config: Store config in the environment
- Backing services: Treat backing services as attached resources
- Build, release, run: Strictly separate build and run stages
- Processes: Execute the app as one or more stateless processes
- Port binding: Export services via port binding
- Concurrency: Scale out via the process model
- Disposability: Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity: Keep development, staging, and production as similar as possible
- Logs: Treat logs as event streams
- Admin processes: Run admin/management tasks as one-off processes
In summary, there aren't specific best practices for cloud-native yet, but there are patterns from Agile, microservices, and the twelve-factor app that are useful to follow.
Hello World with Payara Micro and Platform.sh
In this section, we will cover how to create your first REST project with Payara Micro, and then move that project to Platform.sh using the Maven Archetype, which is a Maven project templating toolkit. An archetype is defined as an original pattern or model from which all other things of the same kind are made. You can generate with the following command:
The next step is to convert it into a Git project, so:
Then, finally, create a new project on Platform.sh, take the git repository address and push your code to master. As soon you push this code to master it will generate the containers that you need to make your application available.
As soon we push the code to remove, it will create the Maven build and deploy the application. In the end, it will generate the IP address, take this address and make a request in the server.
The Maven Archetype we'll generate includes the Maven dependencies and the three files that Platform.sh requires to move this application to the cloud. Now, let's go deep into this file and talk about the components one by one. To explain further, these files represent the concept of infrastructure as code - the process of managing and provisioning computer data centers through machine-readable definition files.
The application file has the configuration to create the application container. The build is defined by a Maven command which creates an uberjar. To create the application container, the file has the following attributes:
name (required) - Sets the unique name of the application container.
type (required) - Sets the container base image to use, including application language and it’s version.
disk and mounts (required) - Defines writable file directories for the application.
build, dependencies, and hooks - Controls how the application gets compiled. Note that this compilation happens before the application is copied into different instances, so any steps here will apply to all web and worker instances.
web - Controls how the web application is served.
A plain "Hello World" app is ready, so let's move forward and create a JAX-RS integrated with a SQL database.
Platform.sh and Payara have created a helpful guide to talk about Jakarta EE and cloud-native.
Opinions expressed by DZone contributors are their own.