Webinar: Accelerate Your Inner Dev Loop for Kubernetes Services
•Download as PPTX, PDF•
0 likes•334 views
The document discusses an approach called Service Preview that allows developers to accelerate their inner development loops for Kubernetes services. Service Preview allows developers to code microservices locally, preview changes immediately with routed test traffic, use local tools like debuggers while treating the microservice as if it is live in the cluster. This is done in isolation before merging changes. Service Preview is presented as a simple way to remedy the complexities introduced to development workflows by containers and Kubernetes without the drawbacks of other approaches.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Webinar: Accelerate Your Inner Dev Loop for Kubernetes Services
Similar to Webinar: Accelerate Your Inner Dev Loop for Kubernetes Services (20)
More from Ambassador Labs
More from Ambassador Labs (20)
Recently uploaded
Recently uploaded (20)
Webinar: Accelerate Your Inner Dev Loop for Kubernetes Services
- 1. Accelerate Your Inner Dev Loop for Kubernetes Services Abhay Saxena Principal Software Engineer, Datawire Jen Dyment Product Marketing Manager, Datawire
- 2. ● Containers introduce complexities to inner dev loops ● Typical approaches to remedy these complexities introduce additional issues ● Service Preview allows you to: ○ Code microservices locally ○ Preview changes immediately with routed test traffic ○ Use your favorite tools (debuggers, IDEs, etc.) locally ○ Treat microservice as if it is live in the cluster ○ Work in isolation before merging your changes ● Service Preview is simple to implement tl;dr
- 4. CODE DEVELOPMENT RUN OPERATIONS TEST ALL QA RELEASE OPERATIONS DEPLOY OPERATIONS Huge Team Microservices Enable Faster OUTER Dev Loops
- 5. DEV DEV DEV DEV CODE DEVELOPMENT RUN OPERATIONS TEST ALL QA RELEASE OPERATIONS DEPLOY OPERATIONS Huge Team Microservices Enable Faster OUTER Dev Loops
- 6. Containers Slows Down INNER Dev Loops
- 7. Other approaches to setting up dev environments have drawbacks Copy 1 Copy 3 MS 1 MS 2 MS 3 MS 4 Kubernetes Dev Cluster Copy 2 Individual Copies of Dev Cluster for Each Developer Issues - $$$ Cloud Costs - Pain to keep up- to-date Running Local Only Development Environments Issues - Requires “64-core laptops” - Maintenance of emulators - Pain to keep up-to-date
- 8. MS2 Code MS1 Code MS1 Code MS 2 MS 3 MS 1 Kubernetes Dev Cluster Edge Requests Dev 1 Test Traffic Typical Traffic Dev 1 Service Preview Proxy Dev 2 Test Traffic Dev 2 Service Preview Proxy Service Preview in the Ambassador Edge Stack
- 9. MS2 Code MS1 Code MS1 Code MS 2 MS 3 MS 1 Kubernetes Dev Cluster Edge Requests SHORTEN THE INNER DEV LOOP Dev 1 Test Traffic Typical Traffic Dev 1 Service Preview Proxy Dev 2 Test Traffic Dev 2 Service Preview Proxy
- 10. WORK AND TEST CHANGES IN ISOLATION MS2 Code MS1 Code MS1 Code MS 2 MS 3 MS 1 Kubernetes Dev Cluster Edge Individually Identifiable Requests Dev 1 Test Traffic Typical Traffic Dev 1 Service Preview Proxy Dev 2 Test Traffic Dev 2 Service Preview Proxy
- 11. Speed of Inner Dev Loop Isolated Code Loops Fidelity of Environment Low Maintenance Efforts/ Costs Scalability 1. Container Approach: Local Changes, Push to Cloud 2. Local Approach: Completely Local, Emulated Services 3. Cloud Approach: Duplicated Dev Clusters 4. Service Preview Approach: Proxies and Routing
- 14. MS2 Code MS1 Code MS1 Code MS 2 MS 3 MS 1 Kubernetes Dev Cluster Edge Individually Identifiable Requests Dev 1 Test Traffic Typical Traffic Dev 1 Service Preview Proxy Dev 2 Test Traffic Dev 2 Service Preview Proxy
- 15. A quick recap... ● Code microservices locally ● Preview changes immediately with routed test traffic ● Use your favorite tools (debuggers, IDEs, etc.) locally ● Treat microservice as if it is live in the cluster ● Work in isolation before merging your changes
- 16. Wrapping Up
- 17. Get Started with Service Preview and Edge Control: https://www.getambassador.io/docs/latest/topics/using/edgectl/ Subscribe to our podcasts: https://www.getambassador.io/resources?types=Podcast Follow us on Twitter: https://twitter.com/getambassadorio Learning More youtube.com/watch?v=LDiyKOa1V_A
- 18. Q&A
Editor's Notes
- Hello and welcome to Today’s webinar! Abhay Saxena is a Principal Software Engineer at Datawire where he is working on building software tools for developers that are adopting or using microservices and Kubernetes. He is currently the lead engineer on Telepresence, an open-source tool for local development of Kubernetes microservices. Over the last 15 years, he has worked in the finance industry building high-throughput systems using big data and machine learning in financial applications in constantly-changing environments.
- Before we jump into the presentation, we like to review what we will be covering at a very high level. First, we will be covering why we built Service Preview and why those that use it love it. Microservices are incredibly useful and exciting, but containers introduce complexities
- Please ask questions! We will leave time at the end of the presentation to answer your questions. If you have a question during the webinar, please ask it at any time in the Q&A window at the bottom of the screen.
- We’ve all seen that adopting a microservices architecture has the potential to supercharge your development cycles.
- Smaller microservice developments teams can own and run individual services freeing them from operational bottlenecks and lengthy release timelines associated with orchestrating large product releases.
- Containers, which are used to implement microservices, introduce new challenges for the inner dev loop. the inner dev loop is iterative process of writing, building and debugging code that a single developer performs before sharing the code, either publically or with their team. This presents two immediate challenges for developers. The first is that container building, uploading and deploying adds minutes to each cycle. These minutes are not only wasted time, but the also break a developer’s workflow, causing them to lose their focus. This really adds up if you are previewing your code 25-75 times a day. Second, reviewing your code in isolation before sharing it is not really possible with a shared staging environment.
- Speaking to many developers, we saw that there are two main approaches for setting up dev environments to tackle these issues of lengthened inner dev loops and lack of isolation. The first is running completely locally. So this entail developers duplicating microservices on their local machine, creating emulated services, and maintaining those environments. We heard stories of destroyed laptops and hours of maintenance. The second is to create individual copies of each dev cluster for each developer. When you have 300+ developers, the cloud costs really add up and keeping these environments up to date is time-consuming for everyone involved. _____ Architecture to speed you up Technologies can slow you down Monoliths -- fast on dev, slow on release Microserivces-- slow on dev, fast on release Inner loop was fast Whole software development life cycle was inefficient Teams didn’t have the agility needed
- To help address these issues, Datawire created Service Preview. Service Preview allows you to leverage a shared staging cluster with the high-fidelity, up-to-date environment that scales well as your application grows in size and complexity. This is of course without having to deal with delayed inner dev loops or a lack of isolation. In this diagram, you can see the typical traffic and how it is routed through the cluster.
- Send individually identifiable traffic through the edge to a specific service Traffic routes through live system before entering the microservice being coded Instead of running the service in remote cluster, traffic is routed through proxy to the code on local computer Traffic is routed back through live system, before egressing at the edge Developer can modify code, debug, and view results through any IDE and/or tool chain of their choice
- The other developers are not affected and can go through the same workflow without affecting anyone else’s environment.
- This table here summarizes the four different approaches on the left and how well the tradeoffs teams must consider when setting up dev environments.