Read on Twitter
I'm livetweeting the http://focus.dotnetconf.net "Focus on Microservices" conference today. Thread. 
There's a full day of "great" content, including Kubernetes.
I don't typically put "Great" and "Kubernetes" in the same sentence, but we'll let that go for now.
I don't typically put "Great" and "Kubernetes" in the same sentence, but we'll let that go for now.
You can get answers to your questions by using the hashtag #dotnetconf .
First up are Scott Hunter and David Fowler (.NET Director of Program Management .NET and architect respectively)
Scott: .NET is the platform for any app you want to build on any platform.
2017: .NET Core released -- 1.5 Million developers using .NET Core (not sure how they got that number)
2017: .NET Core released -- 1.5 Million developers using .NET Core (not sure how they got that number)
Most loved framework on the Stack Overflow developer survey (no one tell them that Stack Overflow skews .NET)
Accordign to their metrics 1 million new developers in the last year.
This, of course, reiterates: Your software is spying on you. They call it 'telemetry', but it's spying. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry
This, of course, reiterates: Your software is spying on you. They call it 'telemetry', but it's spying. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry
Goal for .NET Core: To get people to upgrade as quickly as possible.
.NET 5 is even faster than .NET Core 3.1. But lol at getting traditional .NET Partners to use Linux.
.NET gRPC perf equals or exceeds Go. .NET Client is 3x faster under heavy load (70 concurrent requests x 28 connections). -- they see Go as a competitor? Interesting. I would have thought Node.js.
.NET now ships every November; and every LTS is every other year. LTS is 3 years of support.
.NET 5 being launched November 10th - 12th during DotNetConf 2020.
Now on to Microservices and why they're "Good".
I don't want to push back against these "advantages", but caveat emptor.
Especially with "Smaller, focused teams". Silos are... good?
Now going through VMs vs Containers and touting containers as important to Microservices -- they make it easier; but Microservices != Containers
Guess what you get to do with Containers? You get to now deal with updating those containers. You now get to make every microservice care about the OS its own and any vulnerabilities in that OS.
Happy Thursday.
Happy Thursday.
Your smaller, focused team now gets to go OS spleunking.
Kubernetes mentioned. DRINK.
Kubernetes lets you orchestrate containers.
It also lets you get liver failure before your time.
DRINK.
Kubernetes lets you orchestrate containers.
It also lets you get liver failure before your time.
DRINK.
"Vendor neutral" orchestration -- for the myth that people will ever actually go cross vendor for their cloud.
Here's how kubernetes works according to this slide:
Not shown: The bash scripts that hold it all together.
Oooh, mention to the OpenAPI standard; which is a way to generate APIs so that they match across all services.
Here's what you now have to learn if you want to learn "Microservices":
Grpc framework with at least Two parts: Proto file that allows you generate classes and methods from it; also uses protocol buffers for high performance. (Note: I've never used gRPC so I'm learning it as we talk).
The top level C# programs (a single file C# program) is interesting to me -- and as someone who learned Perl first back in 2000, I'm glad C# is finally there. :-D Also allows you to remove a lot of the ceremony with creating a service.
Fun fact, back in .NET Core 1.0 days, http://ASP.NET Core applications were just console applications. I remember getting a lot of hell from @anthonymastrean when he tried to update a service I wrote in .NET Core 1.0
Project Tye: Scaffolding and tooling for .NET based Microservices. I haven't used this; but when I was doing Microservices the tooling was... not great. So this looks interesting.
One of the 'features' of Microservices is that you don't need to have all your services be on the same language; but in reality your team gets kinda cranky when you create a Perl based Microservice.
I will neither confirm nor deny that I did this.
I will neither confirm nor deny that I did this.
One of the better parts of Microservices is getting developers out of installing dependencies on their Host OS, and instead pushing down things like local databases, redis, message brokers into containers. That's the big win for Docker for me is how it enables developers.
Now it's demo time. They're showing off a..Microservice? (this is a live tweet, I don't claim it to be accurate, only it to be live).
They mention Swashbuckle, which is a pretty neat way to show off your API and allow consumers of your API to interact with it with very little extra work on your part.
Seriously, if you have a public API (even if "public" means other internal teams) you should think about adopting Swagger and Swashbuckle.
Also, if you want to know someone who has run into every dark corner that exists in Swagger and Swashbuckle, talk to @anthonymastrean. That man is a lightning rod for unusual application behavior.
I missed the opening to this; but they're showing off an HTTPRepl from the command line that allows them to work with this through the command line. Wish I hadn't missed that; but taking a screenshot in windows is a multi step process for me. (I use Snipping tool)
Wow, So that's what Service Reference is for. Now with "connected services" you can use OpenAPI or gRPC.
SOAP IS NO WHERE TO BE FOUND.
REJOICE
SOAP IS NO WHERE TO BE FOUND.
REJOICE
There's some magic going on in this service; they were able to basically able to inject the swagger client with a shortcut? I didn't see what buttons they hit; but they either copy and pasted it in or it was auto discovered? Unclear.
and now gRPC. It's pronounced "grapesy" if you work at Amazon, G-R-P-C everywhere else.
I don't make the rules.
I don't make the rules.
Grpc service in action. This is the proto file I was talking about earlier.
And the server side of using gRPC:
Once again using Service Reference to create the magic from the proto file (this is what I missed before)
Apparently this entire client was created from that magic and typing "grpcclient".
Microsoft is *very good* at introductory magic;
What most teams find is that the introductory magic wears off with any hard application. This is still cool tho.
What most teams find is that the introductory magic wears off with any hard application. This is still cool tho.
Hehe, they just minimized a window to find @csharpfritz texting. Surprise
I wish instead of using IISExpress they would improve the IIS tooling to just automagically create what a developer needs in IIS regular, to include local domains.
Yea, I said it.
Yea, I said it.
Now they're showing off the single file publish which I am stoked about
WSL makes an appearance; launching a local web app from WSL and getting it to show that it's running on... unix?
Unix 4.19?
Is there anything called Unix with a version of 4.19?
Is there anything called Unix with a version of 4.19?
Next demo is @davidfowl showing off Blazor?
Nope, looks like it's about Tye.
Again, Live, not Accurate.
Again, Live, not Accurate.
BlazorServer is involved, hence my confusion.
I'm not even sure what BlazorServer is. Isn't that just... http://ASP.NET ?
I'm not even sure what BlazorServer is. Isn't that just... http://ASP.NET ?
David Showing off how all the code is generated from Service Reference. This is pretty fricking awesome; but also reminds me how often Code Generation bites us in the posterior.
BlazorWeather.Server is a "Server Side" blazor application.
That's running as a client?
I have no idea what this means.
I'll get better, I promise.
That's running as a client?
I have no idea what this means.
I'll get better, I promise.
Ah. Blazor lifecycle looks a lot like the WebForms lifecycle.
Oh no.
Oh no.
If you aren't cringing from that comparison, you haven't run into problems with Webforms lifecycle, and I admire you.
One of the problem with going pretty fast in the live demo is that it's hard to tell what problem they're solving or why.
So I'm left watching a cool demo that I have no idea what problems it solves or why.
So I'm left watching a cool demo that I have no idea what problems it solves or why.
Ok; here's how it all Tyes together.
Hahahah. I'm here all day.
They're using tye run to run everything they need to run so that the server and client run together.
It TYEs them both together.
Get it?
Hahahah. I'm here all day.
They're using tye run to run everything they need to run so that the server and client run together.
It TYEs them both together.
Get it?
here's the tye dashboard showing that everything is running thorugh the magic of 'tye run'.
I'm gonna get some mileage out of the tye pun, I can feel it.
Also shows logs on the tye dashboard for all services. Wonder if tye supports tail -f for those of us that like consoles instead of a web page?
I guess I can open the logs myself with tail -f; but can I find them through tye? #dotnetconf
If I am running 10 services through tie; how do I search their logs easily while it's running? That's the problem I'm trying to solve #dotnetconf
A common problem in docker is getting to the logs easily. Btw I hope they fixed the issue with Docker not necessarily capturing all the logs due to streaming and flushing issues.
If you've never run into that I admire you; once again I think it's because @anthonymastrean is a lightning rod for finding unusual behavior in all tooling
Yaml and kubectl make an appearance.
It's pretty impressive how the worst standards become the most popular. I'm looking at you, yaml.
It's pretty impressive how the worst standards become the most popular. I'm looking at you, yaml.
David now showing how he is able to interact with a Raspberry Pi running this client from tye.
wrapping up the keynote with the recap:
we're in break mode so I'm gonna utilize the latrine, as they used to make us say in the Army.
DUring this commercial break; if you're interested in hearing about what happens each week in .NET, you can join the newsletter at http://www.lastweekin.net . If you prefer to consume with your ears, you can do that at http://podcast.lastweekin.net
I will not apologize for the cool fact that http://lastweekin.net was available. Also finally it being named ".NET" becomes a good thing.
Brendan Burns is up talking about why you should care about Microservices.
He works at Azure.
Azure would love it if you adopted Microservices so that you can deploy them on Azure.
He works at Azure.
Azure would love it if you adopted Microservices so that you can deploy them on Azure.
More services, more usage, more money.
Brendan starts with truth: You don't care about Microservices.
He's right. We don't.
Right now I'm on the "They're a solution in search of a problem", but again, this isn't my conference.
He's right. We don't.
Right now I'm on the "They're a solution in search of a problem", but again, this isn't my conference.
Service Oriented Architecture was pretty awesome; but the word 'Micro' ruined microservices.
He asks "What do you care about"?
I care about easily solving problems and when I need to using code that makes it easy to solve problems.
Easy and Microservices don't mix.
I care about easily solving problems and when I need to using code that makes it easy to solve problems.
Easy and Microservices don't mix.
Brendan:
You care about your product.
You care about your users.
You care about your product.
You care about your users.
"You care about your team - Brendan Burns" -- Michael Scott.
I hope this turns to the 'good' for Microservices; because so far all these are reasons why I wouldn't adopt Microservices given the opportunity.
Remember: Microservices is a technical answer to a political and structural problem large organizations face.
You probably don't work at a large organization.
You probably don't work at a large organization.
Unless you work at a Fortune 500; you probably don't need Microservices -- even if you do work a a fortune 500 you don't necessarily 'need' them. They will make your life more painful and amplify any communication problems you already have.
But again; that's me, not Brendan.
Brendan is talking about how Microservices is OO Programming reimagined across executables.
He's right -- but with the level of tooling that makes us yearn for the days of a compiler to enforce contracts.
Brendan is talking about how Microservices is OO Programming reimagined across executables.
He's right -- but with the level of tooling that makes us yearn for the days of a compiler to enforce contracts.
"Building software isn't hard" - Brendan Burns.
Me:
Me:
Ah, "Building Software as a team is hard"- Brendan Burns.
Yes, people make things more complicated. So if we introduce microservices, we can build software that allows us to ignore other people (teams).
Yes, people make things more complicated. So if we introduce microservices, we can build software that allows us to ignore other people (teams).
"Microservices aren't really an architecture for delivering software [..] Microservices are about scaling teams." - Brendan Burns.
Me:
Me:
I just started watching "The Office" for the first time so I'm gonna be dipping into that well for gifs.
You're welcome.
You're welcome.
"The ideal team is 5-6 people"
That's probably true, but I'd recommend even numbers where possible. Odd numbers have... odd things happen.
That's probably true, but I'd recommend even numbers where possible. Odd numbers have... odd things happen.
Remember, this talk is about Why you should care about Microservices.
Small teams:
YOu can understand the code
You can understand the team
You can talk to each other.
Each person can have 3 slices of piece from that 2 pizza team.
YOu can understand the code
You can understand the team
You can talk to each other.
Each person can have 3 slices of piece from that 2 pizza team.
Math is not my strong suit but I stand by that 3 slice rule.
Brendan says "Most projects require an army (eventually)"
No one bring up Instagram or tumblr. Please.
No one bring up Instagram or tumblr. Please.
I don't want to push back to hard, but what in the ever loving frack is that statement.
NO THEY DON'T.
In fact, very few projects will ever require an army.
The only time medium sized projects require an army is when the C-Suite is off their rocker.
NO THEY DON'T.
In fact, very few projects will ever require an army.
The only time medium sized projects require an army is when the C-Suite is off their rocker.
When the executive says "If you give me nine women we can have nine babies in nine months", that's the sort of person who will want your developer team to "be an army" so you can "go faster".
I will neither confirm nor deny an executive told me that once as a way to get us to make the team bigger and 'go faster'.
I heard they claimed to have read the mythical man month.
I heard they claimed to have read the mythical man month.
In case I'm not clear: If an executive ever says any of those things to you or you hear them, RUN AWAY.
Brendan gets to software being modular and needing "bigger teams"; and so we're getting to the burn about Microservices being the answer.
I mean, the conference is *about* Microservices, so they couldn't very well say "We're full of shit about this"
I mean, the conference is *about* Microservices, so they couldn't very well say "We're full of shit about this"
(Also, if you want a great talk about the benefits of Microservices; see this talk by @ChadFowler) :
Microservices aren't for everyone, and they have a lot of plumbing you now get to worry about that you don't in a monolith; but if you've found that you can't change the culture but you can change the software, Microservices may be the answer.
I mean, Microsoft's org chart looks like this; so I get why Microservices would be useful there:
The argument it appears Brendan is making for Microservices is it enables you to scale your teams. Most of you will never have that problem.
Also, as a point of feedback for #dotnetconf can you all include your twitter account at the bottom of all your slides so I can appropriately mark who to follow?
It doesn't appear like Brendan Burns is on twitter; but he sounds cool and I'd say to follow him if he was on twitter.
Twitter handles are available here (thanks @bethmassi!) https://focus.dotnetconf.net/speakers
You can find Brendan Burns on twitter here at @brendandburns
HE's THE KUBERNETES COFOUNDER.
That explains a lot.
That explains a lot.
Also a Corporate Vice President at Microsoft, working on @azure. (I'm regurgitating words on pages here; I have no idea what any of that means)
Now Brendan is talking about services per person on a team. Says "You won't get service boundaries right on the first try."
Neither the second or third, plan accordingly.
Neither the second or third, plan accordingly.
Programming note: I don't @ people talking with everything they say because it'd be cruel for them to come back to 100 tweets from me because I was quoting them. People love clean timelines; and I agree.
"If we break things part into services but we don't empower our teams, we've made things harder."
"Local autonomy requires trust".
- Brendan Burns
"Local autonomy requires trust".
- Brendan Burns
If you adopt Microservices, you need to have a deprecation policy for your APIs.
(Spoiler: I'd argue that your communication mechanisms should reflect CQRS, and your API is the 'q' side of that; with a message broker or some other asynchronous process for the 'command' side)
(Spoiler: I'd argue that your communication mechanisms should reflect CQRS, and your API is the 'q' side of that; with a message broker or some other asynchronous process for the 'command' side)
If you adopt microservices, you need documentation.
Many teams will fall down here. it's hard enough to get people to write Docs; but if you have Microservices, YOU NEED DOCUMENTATION.
Many teams will fall down here. it's hard enough to get people to write Docs; but if you have Microservices, YOU NEED DOCUMENTATION.
OpenAPI and code generation can help here; Swagger is a nice tool for that, but again, I'd recommend using APIs for querying only. Seriously.
Microservices introduce the idea of SLO, and Quality of Service (let's all talk about message brokers and recording locally the data you need to get your job done)
Heresy, of course; but resilience means copying data.
This is why teams who adopt Microservices have higher rates of liver failure.
This is why teams who adopt Microservices have higher rates of liver failure.
Oh, Chik-Fil-A is here; I may need to pause while I grab my food.
came back to this slide and I don't have the context but I agree
Also, my experience with Microservices may not be yours. Act accordingly. Also I wrote about my experience here: https://georgestocker.com/2019/01/21/microservices-after-two-years/
Brendan is dogging on XML, which is pretty cocky given how terrible Yaml is.
Who loves whitespace being significant?
Python programmers, of course; but they don't have a good gif.
Brendan is wrapping up; I'll sum up here:
- The focus is on scaling the team
- Think in APIs (todays answer to "Think in Classes" for OOP)
- empower your teams (get away from architecture boards)
- build on shared infrastructure
- The focus is on scaling the team
- Think in APIs (todays answer to "Think in Classes" for OOP)
- empower your teams (get away from architecture boards)
- build on shared infrastructure
Those were his closing thoughts btw. You can find him on twitter at @brendandburns
Next up is @kelseyhightower talking "Stay sharp".
Sounds like it's going to be learning new things. I agree with his advice; I've averaged at least one new production language every two years since I started programming and although it's frustrating starting out; you start to see patterns and new languages get easier.
Don't know if I'd be able to learn Rust however. Also I tried debugging a RabbitMQ problem and I couldn't make heads or tails of erlang.
I'm probably not Strangeloop material.
I'm probably not Strangeloop material.
Kelsey: "I don't use an IDE".
(if you write C# and work in .NET, Visual Studio is pretty bad ass. I wish every IDE had its level of awesomeness).
(if you write C# and work in .NET, Visual Studio is pretty bad ass. I wish every IDE had its level of awesomeness).
Kelsey is demoing Go, and if any language could use an IDE, it's Go.
Go "strings" still freak me out
Kelsey is contra go single file approach with C# and trying to use Program.cs the way you would use a go main file.
Btw, this is a fundamental difference between languages; and one of the reasons why I'm glad for Single file C# programs. Hanselman breaks down what .NET means
I loved the single file approach to Go; but Go has this weird environment setup that still throws me off. Every language and environment has its quirks.
GOPATH is something that strikes me as weird and I don't understand it; but the go people apparently love it.
"I just dont' use an IDE".
If you're going to program in .NET, you won't love the ecosystem in Vim. It'll seem rather esoteric in fact.
If you use Visual Studio, you'll see how powerful and pretty amazing .NET is.
Maybe that's a failing of .NET?
I see it as a feature.
If you're going to program in .NET, you won't love the ecosystem in Vim. It'll seem rather esoteric in fact.
If you use Visual Studio, you'll see how powerful and pretty amazing .NET is.
Maybe that's a failing of .NET?
I see it as a feature.
Kelsey: "I think .NET Core is the best thing to happen to the .NET Ecosystem in a long time"
You're right in more ways than you can imagine.
You're right in more ways than you can imagine.
The nice thing about Kelsey's talk (there are several) is that he's showing how the other half operates; and that's something a lot of professional .NET developers probably haven't seen before. It would be alien to them.
Also if you're using Docker, look at Alpine linux. https://docs.microsoft.com/en-us/dotnet/core/install/linux-alpine It's a very small linux distro; but it uses musl I think which is a bit different than glibc; and that may bite you.
Anyone who does Microservices full time: If you care about container size; does anything beat Alpine that supports .NET Core?
Kelsey is referencing his "12 fractured apps" blog post; haven't read it but gonna link it here: https://medium.com/@kelseyhightower/12-fractured-apps-1080c73d481c
Kelsey "Code is a liability". First time I heard that was from @ChadFowler but he maybe wasn't the first person to say it? It's one of those interesting trends in software that I'd love to dig deeper and see where and when it started.
tehre's a weird echo on #dotnetconf with @CSharpfritz and @kelseyhightower, not sure what's causing it.
Whoever is running sound at #dotnetconf can you fix this?
W00t. FIXED. THANKS #dotnetconf sound mixer person
Kelsey: Container Images make universal application packaging possible.
HELL YES. Running a database in a container is suicide but holy hell it is a lot easier to install and configure a database using a container file.
HELL YES. Running a database in a container is suicide but holy hell it is a lot easier to install and configure a database using a container file.
They're in Q&A right now.
Kelsey: you know a microservice that no one thinks of as a microservice?
DNS.
Me:
DNS.
Me:
On my phone the video is talking about authorization and on my desktop they're talking about headers being put into the tracing library. Ah. Video on phone is behind by 5 minutes. interesting.
Q: Thoughts on using Dapper to run Microservices applications as an alternative to kubernetes.
Me: Dapper is a database microORM.
Them: We said "DAPR", not DApper.
Naming is hard I guess.
Me: Dapper is a database microORM.
Them: We said "DAPR", not DApper.
Naming is hard I guess.
Microsoft loves to compete with open source so much that it'll even take their names.
Microsoft can't really claim to "not know about Dapper" given that it's a pretty big .NET project from their most well known non-microsoft user of .NET: Stack Overflow.
It's also telling that Microsoft hasn't changed the name though I'm sure they've been made aware of the naming issue at this point. It reinforces the "we're big and will do what we want and I'm sorry if that inconveniences you".
Anyway, there was a probably a good answer by Kelsey there and if I weren't entirely thrown off by the mention of DAPR I would have captured.
Next up is "A Journey into .NET Microservices with Steeltoe", featuring David Dierfuf, on twitter at @DierufDavid
Steeltoe is a framework for creating Microservices. I think. It's called Steeltoe for reasons I don't get but chalk up to "Programmers either steal naming conventions or name things with cute puns". https://steeltoe.io/
David: "Steeltoe makes creating .NET core microservices easy. But we have to agree on a few things:"
David:"You're going to the cloud."
Me:
David: "Gotta capture logs, metrics, and health"
Me: Paging @honeycombio
David:"You're going to the cloud."
Me:
David: "Gotta capture logs, metrics, and health"
Me: Paging @honeycombio
I assume with this setup that Steeltoe makes these things easier?
Will find out.
Will find out.
David: "Circuit breakers aren't easy" (He's right, but Polly helps out with that a lot).
If you want to be a cloud-native rock star you need to rm -rf random environments to simulate destroying a hotel room.
rock-star is one of those tech things that I can't wait to die.
Steeltoe was "donated" to the .NET Foundation in 2017. Purpose is to let you write better .NET Microservices.
"Cloud Native" isn't really "Use containers in the cloud", but I'm not a cloud guy, @quinnypig is and I heard him say that once I think.
Demotime: Steeltoe.
"Mandatory Visual Studio".
"Mandatory Visual Studio".
It'd be wild if in 10 years most of .NET Developers didn't use Visual Studio.
That day is not today, however.
That day is not today, however.
David is using Steeltoe to set up the following for his Microservice:
Tracing each call
Logs
Healthchecks
He drops into nuget to download:
Steeltoe's packages:
EndpointCore
DynamicLogger
TracingCore
Tracing each call
Logs
Healthchecks
He drops into nuget to download:
Steeltoe's packages:
EndpointCore
DynamicLogger
TracingCore
With three lines of code (after installing those packages) you can have streaming logs, healthchecks, and tracing:
.AddHealthActuator()
.AddInfoActuator()
.AddLoggersActuator()
.AddHealthActuator()
.AddInfoActuator()
.AddLoggersActuator()
By adding "AddDistributedTracing()", you get OpenTelemetry's approach to tracing.
So I guess four lines; again livetweeting, not accuratetweeting.
Live Demos:
No judgment, if you've never had a live demo blow up in your face you're very lucky.
Turn around three times, spit and curse so as not to incur the wrath of the guy high atop the thing
Turn around three times, spit and curse so as not to incur the wrath of the guy high atop the thing
If you don't know the reference, I present, the West Wing:
Not sure how this happened but the thread broke and continues here: https://twitter.com/gortok/status/1288902771291414528?s=20
