- #MICROSERVICES DEPLOYMENT USING DOCKER AND KUBERNETES SOFTWARE#
- #MICROSERVICES DEPLOYMENT USING DOCKER AND KUBERNETES CODE#
Now, on day one at Figure Eight, new engineers can get the first-hand experience with deploying our entire platform, and valuable insight into which microservices depend upon which infrastructure components. DevSpace is a powerful tool for managing Kubernetes deployments without much prior knowledge and has helped us to provide our platform in a box to new engineers starting at Figure Eight. If their dependencies don’t exist, we fail fast, and provide valuable feedback to the user.īeing able to deploy with a single command is just part of what the DevSpace CLI tool brings to the table. Now, when we deploy microservices, we can have them check their dependencies before they are deployed. No need to craft any Helm charts, or craft and manage any yaml files for our microservices or databases. From the root directory of the repo, I was able to runĪnd has the backbone of our platform deployed. Getting Started, AgainĪfter identifying a desirable candidate from our stack of microservices, I set about implementing a POC.
#MICROSERVICES DEPLOYMENT USING DOCKER AND KUBERNETES CODE#
It promised Kubernetes resource management with a more reasonable learning curve, secure multi-tenancy with namespace isolation that provides sandboxed deployments for engineers, and hot code reloading from local machines to pods running on a remote cluster. Enter the DevSpaceīased on a recommendation from another engineering team member, our core platform team decided to vet the Kubernetes developer tool DevSpace as a possible solution to our local development woes. This certainly isn’t the first company for which I have worked that has faced similar problems distributed systems and microservice architectures present real challenges for engineers following local development paradigms. This story probably sounds familiar in the age of microservices, containers, and container orchestration technologies. This did the trick (though obviously didn’t make my RAM very happy) so I checked this script in and articulated it to the team as a useful way to get around some of the headaches of running our stack locally. After running into these gotchas for a few deployments, I wrote a script that would bring up the infrastructure components first, then check to see if those services were healthy before attempting to bring up our Figure Eight applications.
The resource constraints of a local development stack in a system this complex aside, I ran into some trouble with race conditions: microservice A would come up and attempt to connect to a RabbitMQ that hadn’t been provisioned yet, or microservice B would come up before its Postgres database was bootstrapped. Right away we had a bit of a problem: even with nothing else running on a MacBook Pro, running even a small number of microservices, along with their databases, messaging queues, and redis instances is going to cause performance issues.ĭistributed systems and microservice architectures present real challenges for engineers following local development paradigms.
We were using docker-compose, so the idea here was to run a single docker-compose up command in each repo, and the application stack would come up. The page walks the user through initial dependencies and set up before moving on to checking out several repos and running their application stacks.
After some time getting my usual development environment set up, I began working from a Confluence page designed to get new engineers up and running with at least some of the microservices in our architecture. When I started at Figure Eight, I was given the usual “getting started” materials for a new engineer architecture diagrams, Confluence pages, GitHub repos, etc. When he’s not writing code, he enjoys reading, studying mathematics and physics, and traveling with his wife.
#MICROSERVICES DEPLOYMENT USING DOCKER AND KUBERNETES SOFTWARE#
He has worked for software companies ranging from mobile analytics and security start-ups to industry leaders in virtualization. He first moved to the Bay Area five years ago, after honing his skills at small software outfits in his native Maryland. Josh Frazier is a Senior Data Engineer at Figure Eight, a human-in-the-loop machine learning and artificial intelligence company based in San Francisco.
0 kommentar(er)
