Most software companies want to concentrate on building amazing apps; they don’t want to spend time managing clusters, pipelines, etc.
At Phlyt, we recommend that clients use a container-as-a-service (CaaS) to allow them to efficiently manage backend processes and free up time to spend on their core businesses. The Phlyt product team has a lot of experience transferring applications to CaaS such as GCP and AWS.
This post is specifically about deploying apps to ECS and how to do it efficiently by using an AWS tool named Copilot. You will learn how you:
Once your application runs on the cloud, you have several ways to schedule jobs.
In PART 1, I was describing Container Networking on CloudFoundry (PWS/PCF) and how to migrate(very easily) your existing apps to benefit from it.
While the advantages are obvious, without a benchmark, you might wonder if you should use Container Networking yet. The second part of this blog is to compare the performance with and without Container Networking.
I’ve been using the same app as PART1. The source code is available on GitHub. I’m running both apps on Pivotal Web Services (PWS). As the GitHub repo is having Container Networking enabled, i have updated it to execute without it. …
CloudFoundry is an amazing PaaS Cloud Platform. I’ve been using it for several years, especially Pivotal Web Services (PWS).
If you are doing microservices and hosting them on the cloud, you probably have the following setup from your Platform. In this example, microservice A is making a request to microservice B. The default behavior forbids a direct communication between A to B. The caller service will have go through the GoRouter first, and will be redirected to the destination service.
With Container Networking enabled, your microservice A can have a direct access to microservice B. Pretty cool, right? This allows…
With the rise of microservices over the last few years, you may want or already built many of them. Doing microservices requires new techniques, tools and rules to be successful. I will post a series of blogs about it.
As any startups (very small team), we’ve started with a monolithic approach to go fast, really fast. Once our MVP was validated and successful, we had to scale both the application and the team, so we naturally switched to a microservices approach to go even faster.
I’ve built many microservices in the past and this time was a good occasion to…