A couple of weeks ago I’ve passed both the AZ-300 and AZ-301 exams. You’re required to pass both of these exams in to get the Azure Solutions Architect Expert certification. After posting a tweet I got a lot of responses asking if I had any pointers on what to learn. Instead of responding to each person individually it makes more sense to share what I’ve used to study and hopefully it’s helpful to others also.

When going through the list of [Skills measured](https://www.microsoft.com/en-us/learning/azure-solutions-architect.aspx?WT.mc_id=AZ-MVP-5003246) you quickly notice this certification covers a lot of stuff in the Azure ecosystem. Everything from Azure Active Directory to Azure App Services and from storage accounts to multi-factor authentication for users. You need to know everything!

At my day job I’m doing a lot of stuff within the Azure ecosystem but mainly focus on PaaS solutions, like App Services, Functions, Logic Apps, Service Bus, Event Grid, etc. All of the other stuff like IaaS, CaaS, security, AAD, hybrid solutions, site recovery are topics I don’t have a lot of experience with.

So while there might be stuff I didn’t know in the PaaS ecosystem, I knew I had to focus my learning on all of the other stuff as most of it is/was a black box to me.

In today’s world we’re receiving an enormous amount of e-mail.

A lot of the e-mail I’m receiving during the day (and night) is about errors happening in our cloud environment and sometimes someone needs to follow up on this.

At the moment this is a real pain because there’s a lot of false-positives in those e-mails due to the lack of configuration and possibilities in our monitoring software. The amount of e-mails is so painful, most of us have created email rules so these monitoring emails ‘go away’ and we only check them once per day. Not really an ideal solution.

But what if I told you all of this pain can go away with some serverless magic and the power of Microsoft Teams. Sounds great, right?

How to integrate with Microsoft Teams?

This is actually the easiest part if you’re a developer.

If you’re already running Microsoft Teams on your Office 365 tenant, you can add a channel to a team to which you belong and add a Webhook connector to it. I’ve created a channel called Alerts on which I added an Incoming Webhook connector.

After having saved the connector you’ll be able to copy the actual webhook URL which you need to use in order to POST messages to the channel.

You’ve probably heard a lot of talk around a new buzzword serverless. It’s a pretty confusing name for an awesome technology/technique.

The main reason the word serverless isn’t a very good one is because it implies there aren’t any servers when using this technique. I found a fairly funny CommitStrip about this topic.

https://www.commitstrip.com/en/2017/04/26/servers-there-are-no-servers-here`

But what does the term mean then?

Well, it means you don’t have to worry about servers anymore. You just upload your software to the cloud provider of your choice and it runs on-demand/by-request. As Mark Russinovich said in an interview with InfoWorld _“I don’t have to worry about the servers. The platform gives me the resources as I need them.”. _Of course the hardware, operating system, webserver, firewall, etc. is all still there, but as a developer and operational person you don’t really have to care about it.

Isn’t this the same as PaaS from a couple of years ago?

The answer is: Yes and no!

Yes, there are a lot of similarities and the serverless offerings from each cloud provider are based upon their current PaaS offerings. Therefore, you could call it an evolution of PaaS.

No, because the ideology is a bit different.

There are dozens of blog posts, articles and books talking about microservices. Some of them talk about the design, other on how to implement and even others talk about why and when to use them.

This post will be a combination of them all. I won’t claim to be the all-time-expert on the matter, but I have read quite a bit on the subject, attended some talks and have had the honor to design (and implement) such a solution a couple of years ago.

First and foremost, it’s important to understand a microservices design is just another standard architectural design pattern. This pattern can help you to create a high-performance, scalable software solution, but it can also bankrupt your company!

The short explanation

If you don’t have much time to read, or don’t really want to, here’s the elevator pitch for microservices:

It’s a set of small (independent) services, each of them able to carry out their own (functional/business) responsibility without having direct dependencies to other services.

The long explanation

Of course, such a short explanation is a bit short, to say the least.

The general overview

The microservices pattern is a combination of several other, well-known, patterns which we probably have been using for a couple of years now. Take for example the Service-oriented Architecture, Event-driven architecture, Database per Service, API Gateway / Backend for Frontend and many more. All of them combined can form an architecture which has multiple small services, all operating individually.