Ask Jesus

Hi, I'm Jesus Bello. I have over 15 years of experience designing, and developing, software for small, medium, and large organizations. I've had the opportunity to deliver products from a diverse set of industries with partners who share the same passion for software engineering.

My areas of expertise are in: Software Architecture, Full Stack Development, and IAAS/PAAS/SAAS Cloud Service Providers.

What is a back-end for a front-end, and why and when to build one?

Backends for frontends are purpose-built server-side applications that provide functionality for a specific frontend application. They often serve as a smart proxy between your frontend applications and your microservices infrastructure. This way, your microservices are nicely decoupled from your client application logic.

They are also very useful when you have multiple client-facing applications, each with its own set features and functionality. Each backend is responsible for aggregating data from your downstream services and delivering it to its respective client application.

It's best to build one if you know you will be interacting with microservices, or if you anticipate having more than one client application for your system.

The advantages of serveless are well known, but what are the concerns that might dictate not to use them?

One of the primary reasons for not using a serverless infrastructure is latency. If your application requires very high throughput, serverless is probably not right for you.

When architecting a new system, or modernizing a current one, how many years of future growth should I be accounting for?

Generally speaking, you'll want to account for about 2 years of steady growth. If you anticipate a spike, then you may want to be a bit more conservative and aim for 3 years. However, I strongly recommend taking advantage of serverless architectures. It will help keep your costs down, and scales with your product's growth.

What can be done to make using AWS an easy process for new developers?

AWS can have a steep learning curve at first. This is especially true if you're a member of a small team and have little experience with cloud providers. However, I've discovered that getting a fundamental understanding of the following concepts can help overcome the challenges presented early on.

In order of importance:

  1. Roles & Permissions
  2. Networking (VPCs, ELBs, Subnets)
  3. Security Groups
  4. Instance Types
  5. Managed Services (ElastiCache, DynamoDB, SQS, SNS, etc)
I am trying to decide between using Redis and Hazelcast for memory cache. What should I be considering?

Managed Services

There are a handful of services that manage Redis clusters for you, such as: AWS ElasticCache, Redis Labs, and DigitalOcean. Whereas, the only managed service for Hazelcast is from Hazelcast.

Cache Client Libraries

Not all Redis clients support near-cache capabilities. You'll want to take this into consideration if you have very high performance requirements. Hazelcast, on the other hand, provides near-cache solutions for Java, .NET, C++, Python, and Node.js. Worth mentioning, Redisson is a Java Redis client that supports a near-cache strategy.


A quick glance of this Google Trends chart demonstrates that Redis is clearly the most popular option.

Google Trends - Redis (blue) vs Hazelcast (red)

Another thing worth mentioning is how familiar your dev, and operations, teams are with a particular tool.

Ask a Question

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.