2021 • The CTO and co-founder of Komodor, a startup building the first k8s-native troubleshooting platform. • A big believer in dev empowerment and moving fast. • Worked at eBay|Forter| Rookout (first developer), A lot backend and infra developer experience (“DevOps”) • K8S fan 😃 Who am I?
2021 1. The Journey Begins 2. First Core Decisions 3. Let’s Talk CI/CD 4. What About Monitoring & Logging? 5. Worth Mentioning 6. Wrapping it Up Today’s Agenda
native company from the ground up • Trying to use industry best practices • Will share things we learned along the way and tools that helped us • Our main goal was simple: Move fast and build the best product for troubleshooting kubernetes The Journey Begins
locally 2. Easier to test & troubleshoot 3. Easier to manage dependencies 4. Doesn’t require super fast scaling TL;DR Think about increasing the day-to-day work, not the time it gets to set up the infra. *We do have k8s experts in the team *Our product helps k8s users Kubernetes vs Serverless
microservices 2. Then we created a big service 3. Then we split the “big” service 4. Now we merge existing “legacy” microservices Current goal: Have 2-3 big services TL;DR Moved due to issues with running locally, testing and component dependencies. TBH, no real need for a small startup. Microservices vs Monolith Netflix Microservices Diagram, Bruce Wong
it’s difficult to sync dependencies • In Komodor, each dir. is its own “microservice” • We had one shared dir. for shared resources • Deploying yaml part of the repo • Deployment is done via an umbrella chart TL;DR Monorepo is super cool for small teams; we did the required work to be able to split it if needed. Monorepo vs Multi Repo
valuable when they are in production. 2. Removing barriers to move to production is critical, and pays off in the long run. 3. Everyone can push to production; meaning, each inidividual is responsible when things go wrong. TL;DR If you feel unsafe deploying, understand what can be done to improve and allocate resources. Commit 🚀 Merge 🚀 Deploy 🚀 Repeat
dockerized using docker multi-stage build 2. Heavily relying on docker caching capabilities 3. Started with CircleCi, super easy to get started. 4. Moved to Buildkite: reduced built+deploy time from 6 min to <1 min, much cheaper, hosted agents, python instead of yamls. TL;DR: Docker can simplify a lot of things, so use it! Also, don’t be afraid to experimenting with new tools - this might really pay off. CI/CD Tools Used
features without deployments and only to a specific segment 2. This allowed us to test features in production and to further increase our release velocity 3. Launchdarkly gave us all of that, plus easy control and visibility TL;DR: Testing in Production is great, as it’s the only place that counts. Think about how you can move there faster. Feature Flags
2021 Why is it important to monitor from the start? • Save time troubleshooting (and it happens A LOT) • Allows you to know when you have problems, before your customers! • Hard to add after the system has grown • Saves time troubleshooting (and it happens A LOT) X2!!! Zero Day Monitoring TL;DR: Really pays off to start when you are still young
monitoring and testing • Works seamlessly with our tech stack (AWS + K8S) • We are extending base capabilities using DD sdk. • Allows us to create monitoring and custom alerts. • Datadog Synthetics Browser & API test Datadog FYI: Worthable open source alternatives: Prometheus + Grafana + Jaeger
• Kibana and Lucene are the standard • Offer native k8s integrations • Easily configure alerts • Pay money instead of rolling out our own infra Logz.io Worthable alternatives: Coralogix, Splunk, LokI, self hosting (don’t)
2021 • Building a (good) cloud native product is HARD and you will make (multiple) mistakes • The most important things are: o Learn from your mistakes o Listen to the team o Identify weak spots by asking: “What are our biggest time spender?” or “Given a month improving our stack - what will we improve?” Build > Test > Improve > Repeat TBH: Even if it’s hard, it’s super fun!
2021 1. Acts as a Backend on top of Postgres 2. Transforms SQL schema to GQL schema, queries and mutations 3. Uses Auth0 as authentication provider 4. Supports row and column level access rules 5. Configuration file is managed in Git repository 6. “No code backend” Hasura Power FYI: Makes frontend development much easier and faster! Postgres + GraphQL = Hasura
get started 2. Super easy to shoot yourself in the leg 3. Talk with people you trust, read/watch real life stories and don’t be afraid to change on the go. TL;DR Building a company in 2020 “A computer lets you make more mistakes faster than any other invention with the possible exceptions of handguns and Tequila.” 🥃+🔫 Mitch Ratcliffe
komodor
devops_vtj
meteatamel
neuecc
uhyo
sat
mokocm
keropiyo
wmsbill
lycorptech_jp
rainerhahnekamp
puhitaku
yamahiro
chriscoyier
yeseniaperezcruz
sachag
scottboms
akosma
afnizarnur
geoffreycrofte
michaelherold
iamctodd
addyosmani
hursman
zakiwarfel
