Lessons Learned: Deploying Microservices Software Product in Customer Environments

on YouTube ↗42m

" summary

JFrog recounts concrete changes: Artifactory migrates from pet to cattle, shipping as Artifactory 5 removes NFS and centralizes license management after Marathon/DC/OS trials where health checks, startup scripts and Mesos node IDs broke licensing. Xray is built as about 8–9 microservices but customers demanded RPM/Deb instead of Docker, forcing extra packaging and flexible paths. Bintray runs 25+ services. Storage shifts to S3‑compatible object stores; default approach is start with container orchestration but deliver RPM/Deb distributions and fewer, consolidated small services.

AI-written summary · about

" chapters (11)

1. 0:00Start
2. 5:53A first step: VM orchestration • Lesson: Separation between the application layer, and the configuration layer. • Example: health check (/api/system/ping). - What is it confirms artifactory web service, and connection to DB and filestore. Best way to test - Problem: It required an authenticated user
3. 9:05VM orchestration • The importance of startup scripts • Issue: Health check starts before application starts • Solutions?
4. 11:55The first Mesos implementation First container based self-healing orchestration of Artifactory - Thank you mesos team for much assistance! - Able to leverage existing mesos capabilities for - Able to leverage mesos-based DB services
5. 14:49Enter Artifactory 5! • Artifactory 5 objective was to take lessons learned from previous cloud-native work First cloud-native ready version of artifactory - Config for HA no longer requires shared storage - Creates mechanism for node cross-tak to share on
6. 16:53Cloud-native deployments of artifactory for Mesos, Kubernetes, Docker Swarm • Broke the first microservice out of the monolith into a second web-application service
7. 20:43Don't overestimate the customer . We released Xray with a cool docker-in- docker install script and as a set of docker containers. . First request from customers: "Do you have an RPM install of that?"
8. 22:10System was architected for enterprise/HA etc. . For the 1.0 release, we built/test it only with the default architecture of all containers created on one server • It took most of a year to find all the issues this caused for us to enable HA and horizontal scalability DevOps!
9. 23:52Flexibility! • Nearly all requests made have been to give customers more flexibility on install - Ability to specify custom paths - Bring-your-own infrastructure - Source of docker containers
10. 26:04But they do have dependencies in order to function - Xray startup script explicitly checks dependencies and introduces a startup order - Makes it easier for a customer less familar with microservices architectures to understand startup
11. 30:08Simple is better - Consolidate infrastructure services across products keep the total number down for on-premises • Start with the enterprise architecture deployment - If you don't honor scalability flexibility at the beginning • Start with a container-orchestration implementation. Understand we can't end there

" related talks

• 01h 04mDeploying and Scaling MicroservicesSam Newman · NDC Sydney 2016
• 41mEfficient Management of MicroservicesAnkush Chadha, Jason Dobies · swampUP 2017
• 33mEnabling MicroservicesSteve Hoffman · devopsdays Chicago 2015
• 42mContinuous Deployment into the Unknown with Artifactory, Bintray, Docker and MesosphereKiril Nesenko, Gilad Garon · swampUP 2016
• 36mJFrog Platform Innovation: Reloading Development TeamsYoav Landman · swampUP 2024
• 07mJFrog Sponsored Session - Narasimha Pai, JFrogNarasimha Pai · Continuous Delivery Summit 2019 - San Diego
• 44mMicroservices: 5 things I wish I'd knownVincent Kok · Codemotion Milan 2017
• 18mGlobal security at maximum velocity: Multi-Region and hybrid DevSecOpsWilliam Manning · AWS re:Invent 2022