Bob Lee III - Breaking Down that AWS Silo
•Transferir como PPTX, PDF•
0 gostou•42 visualizações
Breaking Down that AWS Silo Bob Lee III Chicago ugroup AWS Community Day | Midwest 2020
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Bob Lee III - Breaking Down that AWS Silo
Semelhante a Bob Lee III - Breaking Down that AWS Silo (20)
Mais de AWS Chicago
Mais de AWS Chicago (20)
Último
Último (20)
Bob Lee III - Breaking Down that AWS Silo
- 2. Breaking Down that AWS Silo Bob Lee III (@therealbliii) | June 11th, 2020
- 5. Tech team structure • Software Engineers • Network Engineers • Security Engineers • Observability Engineers • Site Reliability Engineers • Deployment Engineers • System Admins • DBAs
- 7. Who should we pick? • Software Engineers • Network Engineers • System Admins • Observability Engineers • Site Reliability Engineers • Deployment Engineers • Security Engineers • DBAs Eenie… …meenie… …minie… …MO!
- 8. …MO!
- 9. Updated team responsibilities • EC2 • RDS • S3 • SNS • SQS • Lambda • VPC • Elasticsearch • Sagemaker • KMS • ECR • Fargate • EKS • Oh, yea. And all that other on-prem stuff
- 10. Pro tip
- 12. Breaking down that silo
- 13. Recognize a problem exists Establish transition agreement Invest time into learning/transition Enforce new responsibilities
- 14. Step 1: Recognize a problem exists
- 15. Step 2: Establish transition agreement
- 16. Step 3: Invest time into learning/transition
- 17. Step 4: Enforce new responsibilities
- 19. Any questions?
Notas do Editor
- My name is BL3 and I want to welcome you to track one! I hope I can start this on a positive foot (no pressure, right)?
- I am sure I am not the only one that started my AWS journey working for a company that previously had all of their infrastructure on-prem Cloud technologies are relatively new First AWS services (S3, EC2, SQS) were released in 2006
- Well defined roles (generally speaking) Everyone knows what they are responsible for and the teams are staffed as such And then the inevitable happens…
- Management starts hearing more and more about the benefits of the cloud from their engineers The cloud will help expedite this upcoming project and will help save us a ton of money! We only need to use a few services! Easy right? Now we just need a team to help us architect this…
- The support decision is likely made to choose a team that already has a vast technical background After this decision is made, that team builds out the architecture, meets the requirements of the project and then…
- PROFIT! It is generally at this time that another project spins up, and then another one, and another one That same somewhat arbitrary team continues to work these projects until…
- Not maintainable
- Integrate key stakeholders early and learn AWS technologies together to avoid the silo For many of you, myself included, it is too late in the game for this Now for what you have all been waiting for…
- Four step process to remediate It is important to remember that these steps will take time; possibly months until a full transition is completed But you need to start somewhere!
- Silos are never a good thing as they cause a single source of knowledge As your AWS footprint grows, this causes stress on the support team in many ways More to learn and understand Constantly working on high-impact and highly visible projects (the cloud is cool and hip, right?) Many new technologies have to be learned to incorporate “best practices” (CI/CD, IaC, monitoring, cloud security, etc) Oftentimes referred to as “bottlenecks” because team expansion is generally unlikely Realistically at this time the engineers know a very lucrative tool in the industry which is highly competitive. If the stress level is too high, you risk losing them to other companies Once the problem is recognized…
- It’s important to note that de-funneling needs to have buy-in from both sides (receiving team and transitioning team) Much easier to enforce responsibilities if management on both sides agrees on ownership This is paramount because this time needs to be considered when planning upcoming work Will not have 40 hours/week to work on other projects/initiatives
- This, to me, is the most important step Again, this is important on both sides Transitioning team needs to work on documentation, knowledge transfer sessions, and the presentations required for them Mostly important on the accepting team because acknowledgement needs to be made that even if you support a small component of AWS, you need to know other “fundamentals” Use DBA as an example This is not just managing “another database”. You need to know of IAM, S3, Security Groups, CloudWatch, VPC details, etc, etc This may require learning IaC components or CI/CD pipelines Strongly encourage your team to pursue AWS certifications, attend AWS webinars, events like Community Day, etc One this is completed…
- This sounds trivial but it is easier said than done when dealing with high profile projects with tight timelines or production incidents The default of “lets ask <original team>” needs to stop It needs to be understood that struggles are okay here; that is the best way to learn And once this is completed…
- Your tech team will look like this! I will reiterate that these steps come from my own personal experience where the transition is still ongoing.