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.
It depends. Two of the most important things to consider are:
If you already have a developer or two that can handle DevOps related tasks, then you may not need a dedicated DevOps engineer. However, while planning your deliverables, you must take into account that this individual's "development" time may be consumed by DevOps tasks. That number can be 80, 20, or 50 percent of the time, depending on the project. With that in mind, larger projects typically benefit the most from having dedicated DevOps support.
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.
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.
Serverless functions are also not built for long running processes. They're great for scheduled tasks that can run within a reasonable timeframe; for AWS Lambda, that's a maximum of 15 minutes.
Another concern is vendor lock-in. Cloud providers have different ways of handling serverless architectures. Once you choose one, it can be very difficult to port your code over to another one.
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.
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:
There are a handful of services that manage Redis clusters for you, such as: AWS ElasticCache, Redis, and DigitalOcean. Whereas, the only managed service for Hazelcast is from Hazelcast.
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.
Another thing worth mentioning is how familiar your dev, and operations, teams are with a particular tool.
