As a cloud native application grows in size—more microservices, more dependencies, more teams—there’s a corresponding increase in… Complexity: Over time, the application becomes a lot harder for a single developer to reason about and contribute to. Staying on top of READMEs and managing cross-team communication is practically a full-time job. Scaling challenges: The reality of building, deploying, and testing a 100+ service distributed application means developers are going to spend a lot of time sitting around waiting. But it doesn’t have to end up this way, and there are concrete steps that DevOps engineers can take to keep their developers moving quickly even as an application grows. In this webinar, we’ll show you how to use open source products to: Make it easy for your developers to code and run on-demand tests against a production-like environment—without having to constantly deal with the complexity that comes with a large application Codify the relationship between all your services and tests, making your system self-documented and easy to understand Keep your integration tests running fast so that devs can more easily write and debug their tests and get the quick feedback loops they need Facilitate remote, in-cluster development and give every developer their own isolated namespace—and never again ask a developer to deploy the application on their laptop

1. Microservices at ScaleHow to Reduce Overhead and Increase Developer Productivity
— Even with 100s of Services

2. What we'll talk about
• We'll focus on the development side of microservices
• The benefits and challenges of microservice architectures
• Particular challenges when dealing with complex applications
• Common tactics for dealing with microservice development challenges
• The opportunities provided by modern tooling and the Cloud Native ecosystem
• How Garden approaches microservice development
• Bonus: Effective strategies for integration/end-to-end testing

3. About Garden
• Founded in 2018
• Headquartered in Berlin,
Germany (with users and
customers around the globe)
• We provide a development
automation platform for cloud
native applications
• Open Core + Enterprise edition

4. Why microservices?
• Monoliths become bottlenecks for larger organizations
• Microservices can map more naturally to your org structure, and allow
independent development and deployment
• Increased resilience and separation of concerns
• More effective scaling and resource usage
• Easier to drop in 3rd party code and services
• Choose the ideal language/framework for each service

5. The
challenges
• Cognitive overhead. How does the
whole thing work together?
What's handled where? How do I
build and deploy each component?
• Many distinct pipelines and
toolchains.
• Lots of time spent plumbing and
configuring.

6. The
challenges
• Difficult and slow to integration/end-to-
end test whole systems.
• Hard to spin up dev/test/preview
environments.
• New security challenges.
• Governance becomes challenging.
• Technology stack fragmentation.

7. Each of these problems grows
exponentially with the number of services.

8. (picture of a spiral around a
swerving line, depicting the
erratic nature of progress)

9. How do we cope today?
• We accept the burden of ever-more configuration, pipelines etc. to
maintain.
• We avoid integration/e2e testing by leaning on mocks/stubs/fakes,
contract testing.
• Actual integ/e2e tests are done in shared staging environments,
potentially in checkpoint pre-flight checks ahead of deployment.
• Maintain separate inner-loop (i.e. local) development setups.
• Rely heavily on GitOps or CI/CD for builds, deployments and tests.
• Develop elaborate, bespoke internal tools for our organization.

10. New technologies,
new opportunities
• Kubernetes provides a (mostly) portable way
to define and deploy applications.
• Declarative configuration and namespaces
make it feasible to spin up production-like
environments.
• Service meshes enable secure communication
across services.
• Observability tools facilitate distributed
debugging and troubleshooting.
• Wide range of other tools available, for
security, storage etc.
• It is an absolute jungle though...

11. Ah yes, the CNCF landscape...

12. Poll: What best describes Kubernetes
adoption at your organization?

13. With our coping mechanisms in place,
what problems remain?

14. Typical software delivery cycle (SDLC)

15. Our unsolved issues
• Local dev environments don't scale, and may not be feasible.
• Remote dev environments are promising, but hard to get going without losing
immediate feedback, or at high cost.
• Integration and end-to-end tests are often sidestepped or done late in the SDLC.
• We cling to yesterday's workflows.
• Too much plumbing overhead.
• Lack of oversight over the full application or stack.
• Application developers are often overwhelmed by level of complexity.
• We need to solve previously solved problems for ourselves, over and over again.

16. How can
we address
all those
problems?
• Standardize on a highly opinionated framework
for all our services (usually not recommended).
• Standardize on certain tools, at least VCS and
CI, across all your applications (definitely
recommended).
• Develop and use better tools and abstractions,
that are reusable across many scenarios.
• Make it easy to spin up dev/test/preview
environments, and to work with those.
• Codify relationships between services, and use
a dependency graph and caches to optimize
build, deploy and test times.

17. • Reduce friction between inner-loop development
and CI/CD, by using the same configuration,
tools and even caches across both.
• Make it easy to spin up production-like
environments for whole applications, both
through automation and ad-hoc by developers
and other stakeholders.
• Leverage a dependency graph (DAG) to reduce
the amount of work needed on every
deployment, test run, whether in CI or during
dev.
The Garden
Approach

18. • Make configuration approachable and scalable
by having every service describe itself, including
how it's built, deployed and tested.
• Enable customized abstractions, to improve
governance and ease-of-use for application
developers.
• Use these environments in combination with
other tools to much more thoroughly validate
your work before deploying to production.

19. A better
development
cycle

20. Simple,
distributed
configuration
• Each component describes itself—
It's a distributed system, so your
configuration shouldn't be monolithic.
• Powerful templating syntax.
• Define your own abstractions
through custom templates.

21. The Stack
Graph
• Codify all the build and runtime
dependencies across your project.
• Garden uses this to only build, deploy
and test what's affected by your
changes.

22. Same tools for
dev and CI
• Run garden deploy or garden
test just the same from your laptop
and from CI.
• Use the same cluster for both, and get
a shared cache between all your
developers and pipelines.
• Waste less time debugging CI!

23. • Garden Enterprise, built on top of
Garden Core, includes:
• Centralized environment
management
• Secrets management
• User management (SSO / RBAC)
• Direct integration with VCS
• Automated environment cleanup
(Q4 2020)
A unified
management
layer.

24. Achieving effective integ/e2e testing
• Make it easy to run individual integ/e2e test suites without starting a
whole pipeline.
• Use application-level mechanics to isolate test data.
• Create isolated "tenants" for each test suite run, that don't affect other
workflows. This can be an organization, team, user, anything that can
be deleted and won't mess with other parallel test runs.
• Generate any mutable test data (or databases, tables etc.) on demand
for each run.
• Don't lump all tests in one suite. Split to different suites based on which
dependencies that suite has. Or more simply, define one suite per service.

25. In closing • We're using microservices because we have to,
but it creates all sorts of complexity. Now the
question is how we can do it more efficiently.
• Modern tools and best practices can bring us not
only the consistency and efficiency that we miss,
but new opportunities.
• By unifying tools and configuration across
development and CI/CD, we can reduce wasted
hours on configuration, maintaining custom
scripts, and waiting for CI pipelines.

26. Q&A

27. Finally, a few bits of advice
• Consider carefully which tools/services/frameworks are standardized across
your org, and which are chosen individually by project/team.
• Make it as easy as possible to deploy dev/test/preview environments.
• Make those environments as production-like as is feasible.
• Make it easy to understand your whole application, its architecture and
dependency structure.
• Reduce cognitive load for your application developers by providing
abstractions.
• Use observability tools for development and testing, not just production.

28. Wrapping up
• We'll send a follow-up email with more detail on how Garden fits
into a day-to-day development workflow.
• Please reach out if we can help or you'd like to discuss Garden
Enterprise: garden.io/contact
• Even if Garden isn't right for you, we're happy to talk because we
learn something from it!
• We're hiring! garden.io/careers

29. Thank you!