DevOps en AWS, acelarando el desarrollo de software con Developer Tools - https://aws.amazon.com/es/devops/
Más informacion: http://aws.amazon.com/es/colombia/
19. Las cosas fueron mucho
mejor bajo este modelo y
los equipos estaban
desarrollando
características más rápido
que nunca, pero sentimos
que aún podíamos
mejorar.
- when you're working with a monolithic app, you have many developers all pushing changes through a shared release pipeline
- this causes frictions at many points of the lifecycle
- upfront during development, engineers need to coordinate their changes to make sure they're not making changes that will break someone else's code
- if you want to upgrade a shared library to take advantage of a new feature, you need to convince everyone else to upgrade at the same time – good luck with that
- and if you want to quickly push an important fix for your feature, you still need to merge it in with everyone else's in process changes
- this leads to "merge Fridays", or worse yet "merge weeks", where all the developers have to compile their changes and resolve any conflicts for the next release
- even after development, you also face overhead when you're pushing the changes through the delivery pipeline
- you need to re-build the entire app, run all of the test suites to make sure there are no regressions, and re-deploy the entire app
- to give you an idea of this overhead, Amazon had a central team whose sole job it was to deploy this monolithic app into production
- even if you're just making a one-line change in a tiny piece of code you own, you still need to go through this heavyweight process and wait to catch the next train leaving the station
- for a fast growth company trying to innovate and compete, this overhead and sluggishness was unacceptable
- the monolith became too big to scale efficiently so we made a couple of big changes
- one was architectural, and the other was organizational
.
- one of the first primitives to emerge was Apollo, a name that we clearly borrowed from Nasa
- Apollo is the deployment engine for Amazon, everything from the retail site to AWS services
- it's how we roll out software changes across our servers
- we first launched Apollo over a dozen years ago
- in that time we've been continually learning about how to manage deployments and baking that knowledge back into the service
- one capability was zero downtime deployments
- there's no way we would allow taking the retail site down just to push a software change
- Apollo supports rolling out a software change without taking down an application
- we also can't let a deployment bug take down the app, so Apollo tracks deployment health and stops bad deployments
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own