DevOne - How to not fail with Azure

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

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.

What about Azure then?
The Cloud comes with lots of best-practices built-in

Amazon Web Services - Products

Google Cloud Platform - Locations

Google Cloud Platform - Products

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

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

Azure or not Azure?
That's just like Java vs. .net

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

How I failed as a Developer
(Developers depicted as Rocket Man?
Dream on, dude)

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

I'll show you how to do that in Azure

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

How I failed as an Operator
(Operators wearing tighs? Sure)

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

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

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.

On to Azure. I'll show you some things

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

How I failed as an Architect
(Architects and brains?
I don't get it.)

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 

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.

I didn't look into new concepts, because I thought
I already know everything I need.

 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

"The Cloud is not about where you run it, but how you build
your systems"

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

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)

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

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 

Don't re-invent the wheel. Build upon what's there

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

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

www.dynatrace.com
Monitoring Hero

DevOne - How to not fail with Azure

More Related Content

What's hot

Similar to DevOne - How to not fail with Azure

More from Martin Gutenbrunner

Recently uploaded

DevOne - How to not fail with Azure