Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOne - How to not fail with Azure


Published on

I made lots of mistakes in my carreer. Here's how the Cloud could have saved me from making them (it just wasn't there back then).

Published in: Internet
  • Be the first to comment

  • Be the first to like this

DevOne - How to not fail with Azure

  1. 1. How to not fail with Azure. As a dev, an ops and an architect Martin Gutenbrunner @MartinGoodwell
  2. 2. About me  Failed in oh so many numerous ways, and learned from it  as a developer  mainly Java, Javascript, a bit of .net, some scripts. From browser to database  as an operator  set up and maintain Dev, Int, and Prod environments; deploy to them and monitor them  and as an architect  with every new project, tried to structure things better, to make projects grow healthier over time.
  3. 3. What about Azure then? The Cloud comes with lots of best-practices built-in
  4. 4. Let's start with a comparison
  5. 5. Amazon Web Services
  6. 6. Amazon Web Services - Products
  7. 7. Google Cloud Platform - Locations
  8. 8. Google Cloud Platform - Products
  9. 9. Azure - Locations
  10. 10. Azure - Products
  11. 11. Azure specifics  more cloud locations than AWS and Google combined  dedicated regional cloud locations, like Azure Deutschland  Azure Stack for your local datacenter to cover hybrid needs
  12. 12. Microsoft
  13. 13. Microsoft is in it's third era now  Bill Gates – A Windows computer on every desk  Steve Ballmer – Enterprise focus  Satya Nadella – Use whatever tech you want; and you can run it on Azure
  14. 14. Azure or not Azure? That's just like Java vs. .net
  15. 15. Disclaimer – What is the Cloud?  The Cloud as such is "just" another datacenter, that's designed to be self-serviceable  "The Cloud is not about where you run it, but how you build your systems"  If you're happy with on-prem, non-cloud, keep doing.  once you reach a certain scale, you might want to think about alternatives.  The Cloud use-case is really about  if downtime is not an option  environments that are too big to be handled manually  be able to scale at any time  scale at a very fine-coarsed granularity – scale single services instead of just duplicating instances  being able to scale also means being able to fail-over  scalability at that level comes at a lower TOC
  16. 16. How I failed as a Developer (Developers depicted as Rocket Man? Dream on, dude)
  17. 17. Um, I didn't
  18. 18. Just joking, of course I did
  19. 19. Don't mistake "failure" for "I wasn't even aware that there's a better way of doing it" You'll absolutely need version control, dependency management, build servers, CI/CD, ...
  20. 20. I'll show you how to do that in Azure
  21. 21. I should have told you about the following things up to now  Use version control – a no brainer  If you're going open-source, share your code from first check-in  because no one's code is perfect  don't say "I'll share, but I'll have to clean up my code first"  Use dependency management  Do Unit-Tests, continuous integration, deployment automation
  22. 22. How I failed as an Operator (Operators wearing tighs? Sure)
  23. 23. I once installed MongoDB manually instead of using the distribution package.
  24. 24. When I had to setup the database server from scratch, I spent half a day looking for that d*mn license file having a VM image would have helped safe so much time
  25. 25. When I first played with the Cloud, all I did was setting up a VM and wondering what all this fuzz was all about until I discovered Infrastructure-as-Code and all the Cloud-specific goodies.
  26. 26. On to Azure. I'll show you some things
  27. 27. aaaaand we're back
  28. 28. I should have told you about the following things up to now  Know, how to spin up all your infrastructure automatically  requires at least VMs, don't run on bare-metal. Ever.  I mean it  Check, whether required databases, queues, etc are available as a service  even if they are more expensive than self-maintenance, check worst-case pricing  Don't just run VMs in the Cloud  Don't lift-and-shift  Makes no op's life easier. Only services do.
  29. 29. How I failed as an Architect (Architects and brains? I don't get it.)
  30. 30. Once we wanted to add MongoDB to our project The problem was, that Ops didn't want us to, because they didn't know how to operate MongoDB Which was lucky, because MongoDB wouldn't have made any sense in that context 
  31. 31. Me and a fellow architect decided to have both of our applications use the same way of authentication by using the same database and tables.
  32. 32. I didn't look into new concepts, because I thought I already know everything I need.
  33. 33. I should have told you about the following things up to now  Don't run for every hype, even though the Cloud makes it much easier to use new technology  And don't use a different language for each problem just because you can.  Focus of tech-choice should be your human resources, not the tech that's optimized to the last bit  Know the trades of what makes a microservice-based architecture  Know about bounded-contexts (Domain-Driven-Design)  You want to share functionality?  Make it a service  But don't just wrap CRUD operations into it's own layer  Be open-minded
  34. 34. "The Cloud is not about where you run it, but how you build your systems"
  35. 35. So, how to actually build your system, so it's "Cloud"?
  36. 36. Lessons learned, for DevOps and architecture  Think about human scalability first, not about technical scalability  If something feels wrong, think again  Right/wrong is not a black/white thing. You might be 80% right already  Honor bounded contexts (this is primarily for devs and architects)  a single chapter in the book Domain-Driven-Design by Eric Evans  Read about microservices, and keep reading. Lots of good blogs out there, especially company blogs  even if you don't want to build upon them.  much of the magic is in the domain model  Practice  Don't expect your first project or microservice to be the perfect one  Start with something of secondary priority / importance  lower traffic, less interdependencies  Don't fix what's not broken (big-bang refactorings, just for the sake of it)
  37. 37. Be a team player
  38. 38. TEAM There is no "I" in ?
  39. 39. TEAM Oh, there is. I've found it: It's in the A-hole.
  40. 40. Productize
  41. 41. Try to productize your workflow. Even if you're a project-centric team. Productizing sets a clear mind for automation of workflows and stuff. Right, but don't over-engineer 
  42. 42. Don't re-invent the wheel. Build upon what's there
  43. 43. PaaS, Service Bus, Application Gateway, Storage, ...
  44. 44. References   
  45. 45. Q & A
  46. 46. Monitoring Hero