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).

1. How to not fail with Azure.
As a dev, an ops and an architect
Martin Gutenbrunner
@MartinGoodwell

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. What about Azure then?
The Cloud comes with lots of best-practices built-in

4. Let's start with a comparison

5. Amazon Web Services

6. Amazon Web Services - Products

7. Google Cloud Platform - Locations

8. Google Cloud Platform - Products

9. Azure - Locations

10. Azure - Products

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. Microsoft

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. Azure or not Azure?
That's just like Java vs. .net

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. How I failed as a Developer
(Developers depicted as Rocket Man?
Dream on, dude)

17. Um, I didn't

18. Just joking, of course I did

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. I'll show you how to do that in Azure

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. How I failed as an Operator
(Operators wearing tighs? Sure)

23. I once installed MongoDB manually
instead of using the distribution package.

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. 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. On to Azure. I'll show you some things

27. aaaaand we're back

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. How I failed as an Architect
(Architects and brains?
I don't get it.)

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. 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. I didn't look into new concepts, because I thought
I already know everything I need.

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. "The Cloud is not about where you run it, but how you build
your systems"

35. So, how to actually build your system, so it's
"Cloud"?

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. Be a team player

38. TEAM
There is no "I" in
?

39. TEAM
Oh, there is. I've found it:
It's in the A-hole.

40. Productize

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. Don't re-invent the wheel. Build upon what's there

43. PaaS, Service Bus, Application Gateway, Storage, ...

44. References
 http://azureplatform.azurewebsites.net/en-us/
 https://cloud.google.com/docs/
 https://aws.amazon.com/products/?hp=tile&so-exp=below

45. Q & A

46. www.dynatrace.com
Monitoring Hero