Five Architectures You Can Quickly Prototype on PaaS

#productivity #webdev #beginners

Sometimes, as an architect or developer, you want to try a new architecture or technical solution but just can't seem to find the time to install, configure, debug, and figure out an entirely new concept. Experimentation is a lot of work, project deadlines come first, and new tech is often one of your last priorities.

However, Platform as a Service (PaaS) can help. One of the advantages of PaaS is the speed and simplicity of pre-configured deployments. You can scroll through a list of options, click a button or two, and have a reference architecture or sample project deployed, running, and ready for experimentation within minutes.

In this article, we'll review five of these architectures you can quickly try out using PaaS. Most all PaaS platforms support prototyping. For our examples, we’ll use Heroku and its “one-click deploys” and Terraform scripts since they are easy to use. You’ll need a Heroku account to get started, though the basic free plan works for most of these examples (I'll note where you need more)

1. RESTful Apps Using the MEAN Stack

The MEAN stack has become a cornerstone of modern web development. Consisting of MongoDB, Express.js, AngularJS, and Node.js, this stack is scalable and extensible. It is often the stack of choice for cloud-hosted apps.
The MEAN stack is also a great place to start for beginners, as the technologies are popular with active communities who can provide help and support. As a bonus, you'll only need to know one language for both the client and server – JavaScript.

Use this one-click deployment to deploy a simple “Contact List” app. This deployment:

Creates a RESTful API service in Express and Node.js
Connects a MongoDB database to the API server
Creates a rich web app using Angular

Alternatively, from that same link, you can walk step-by-step through a tutorial to create and deploy the app yourself.

2. Asynchronous Web Workers

Long-running server requests can kill the performance and scalability of your app. The standard way to handle these issues is to use asynchronous web workers to complete the task. Moving the long-running tasks to background workers frees up resources and keeps your app responsive.

Example architecture using background services for tasks

One popular way to implement asynchronous web workers is with a queue. A queue takes work requests from the client, stores them, and guarantees hand-off to a pool of workers. This reference architecture implements this very design using Java, Spring MVC, RabbitMQ, and AMPQ.

To get started, you can easily clone this project for your own experimentation. The project creates:

Web - A Spring MVC app that receives web requests and queues them in RabbitMQ
Worker - A standalone Java app using Spring AMPQ to read and process the messages from RabbitMQ

The reference architecture also includes a walk-through of the key classes in the project.

For another quick deploy example of queues, check out this article on creating a queue with RSMQ and Reddis.

3. Reactive Integration with Salesforce

Salesforce is ubiquitous in the tech community. Its tools and platform are used for a wide variety of purposes well-beyond basic CRM. Tying into the Salesforce ecosphere to watch or react to events is a common need.

This reference architecture takes advantage of Salesforce Platform Events and Change Data Capture to create an app that responds to Salesforce activity.

The app has a web-based UI and two server-side processes:

stream-consumer.js – The Salesforce Streaming API consumer
server.js – Serves the web app and API feed of account changes to the web browser

Here is the basic architecture of the deployment:

Overview of reactive integration with Salesforce

This deployment takes a little more than just a single click, since Salesforce setup can be pretty involved. However, this sample app should give you a quick and easy way to understand and test Salesforce integration.

4. Event-Driven Microservices

If you’re an enterprise architect, you’ve probably heard of, and worked with, a microservices architecture. And while you might have used REST as your service communications layer in the past, more and more projects are moving to an event-driven architecture. Event-driven is popular when:

You have a large number of microservices that need to communicate asynchronously.
You want your microservices to be decoupled, fungible, and independently maintained.
You have one or more services that produce events that need to be processed by many services.
You want to use a microservices communication pattern that is more decoupled than the typical HTTPS approach.

With this reference architecture you can deploy a full, working implementation of an event-driven Apache Kafka architecture consisting of a client, producers, consumers, and dashboards. You’ll need to do a little prep work on your environment first, but once it’s set up, you can deploy this entire sample project using just a one-click Terrascript.

For a more detailed look at this reference architecture, check out this article on stream processing.

*Note: You'll need a standard plan to deploy this reference architecture.

5. Private Multi-Cloud Communication

If you’re running an AWS service such as Redshift or RDS in an Amazon VPC, you may be looking for a way to connect your app to those services over a private connection. This sample project implements private, multi-cloud communication so your app can communicate with your AWS services privately, without traversing the public internet.

This may be useful if you’re using an Amazon Redshift cluster to analyze data. You can connect the VPC to your application and securely transfer data from your Postgres database to the Redshift cluster for analysis.

This Terraform script is easy to deploy and creates a simple implementation of private multi-cloud communication. When you run the script it:

Creates an Amazon VPC together with an Amazon Redshift Cluster
Peers the Heroku Private Space and the VPC, and sets up the appropriate security groups
Deploys a Redshift client application to Heroku that connects to the Redshift database

Private multi-cloud communication