|
Are young deer fawned of each other?
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Get thee be-hind me! Have you no hart?
(Edited)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
modified 4-Jul-18 13:48pm.
|
|
|
|
|
a bucks nightmare: be havier[^]
...and that's what the wife [when angry] is really suggestion when you [think you] hear, "your best behavier dear."
This internet thing is amazing! Letting people use it: worst idea ever!
|
|
|
|
|
I guess veal find out. 
... such stuff as dreams are made on
|
|
|
|
|
I don't caribout this.
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
Dave
|
|
|
|
|
I have no antler for that.
|
|
|
|
|
I'll wager a fair amount of doe, say 100 bucks that they are.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Oh deer, I herd that!
/ravi
|
|
|
|
|
I doen't know; let stag some and fhind out.
|
|
|
|
|
It seems my current project needs to hop on the Microservices boat.
Does anyone have experience with Microservices on Service Fabric in Azure?
If so, how's the learning curve, what are the gotcha's, and how's your overall experience?
For now it seems I'll have four or maybe five services of which one or two will be web APIs.
The others will read from a Service Bus queue.
|
|
|
|
|
Quote: Microservices on Service Fabric in Azure
OK I am now thinking someone at M$ is naming new products from the Laura Ashley catalogue.
|
|
|
|
|
Sander, why Service Fabric? Why not Kubernetes? The thing is Service Fabric apps are easier, but the problem is they are strictly tied to the Service Fabric runtime. This can be a benefit, in cases where other apps are also deployed and managed by Service Fabric. But leaving that framework can give you accessibility of a wider ecosystem. Service Fabric was open sourced, yet, it doesn't rule out the case where the app has to written for Service Fabric. Kubernetes can help you leave this hurdle and write services independent of the underlying platform.
Azure Kubernetes Service (AKS) Documentation - Tutorials, API Reference | Microsoft Docs
I personally use Azure Container Service for Kubernetes, and I think that is quite simple and easier. Just build Docker images, deploy them as services on Kubernetes. Your 4-5 services can be easily deployed on Kubernetes, and rest is just your YAML file in Kubernetes telling the engine what to do.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Service Fabric because it's Microsoft and Azure and everything I currently do is Microsoft and Azure.
I'm not using Docker at all.
I'm a single developer on a pretty big project so if Service Fabric is easier then I'm all for it 
For the moment I'd rather learn Service Fabric than Kubernetes AND Docker...
Good tip though, I'll keep it in mind for my next Microservices project 
By the way (unrelated), a few weeks back I Googled something and I stumbled upon a post that I followed and which solved my problem.
When I reached the bottom and the "about the author" it turned out to be you!
I can't remember what it was, but thanks for solving the problem I had at the time 
|
|
|
|
|
Platform independence is a myth that's been propagated throughout the history of software. Using Docker makes you just as dependent upon Docker as using Service fabric makes you dependent upon Azure. Whatever you use you're taking a dependency on it, so pick what you like the look of and are most comfortable with and move on. Not voting for Docker or Service Fabric here, just developer pragmatism.
|
|
|
|
|
Sorry, no experience with that, but maybe you will find the Dzone website interesting:
https://dzone.com/
It has lots of information about DevOps, not very Microsoft orientated though, mostly about Docker and Kubernetes 
But I found something about Service Fabric: https://dzone.com/articles/microsoft-azure-service-fabric-as-a-platform-for-d
|
|
|
|
|
Yeah, I get there from time to time
Article looks good (especially the image with the misspelled "Stateful", including squiggly red line to point that out  )
|
|
|
|
|
It always amazes me how the corporate world can take an incredibly simple and elegant concept like microservices and turn it into a bloatware of money grubbing terminology and overly complex implementation and management layers. But then again, how else are they going to make money?
|
|
|
|
|
Marc Clifton wrote: an incredibly simple and elegant concept like microservices
How is scaling up and down servers and spinning up new instances dynamically incredibly simple? 
|
|
|
|
|
Sander Rossel wrote: How is scaling up and down servers and spinning up new instances dynamically incredibly simple?
What does that have to do with microservices? (It's quite possible I'm demonstrating my ignorance of the topic here -- foot in mouth time?)
|
|
|
|
|
SF allows you to automatically spin up and shut down VMs running your microservice instances, based on a schedule or just reacting to periods of heavy use. Coupled with auto-scaling of storage (e.g. CosmosDB) you can meet the demands of peak usage whilst keeping the hosting costs to a minimum.
Adam
|
|
|
|
|
thanks for the use case
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I've just realised that it reads like a sales pitch from MS... not intentional!
|
|
|
|
|
adambl wrote: not intentional!
Supposed so
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Prepare to chew some foot
One reason to work with microservices is that you can deploy the services independently.
If you have a sales service and a stock service you can implement new features in sales and deploy them as a single unit, no need to build and test stock so deployments should be fast and cheap (and different teams can work on and deploy different services independently).
That also means, unlike traditional monoliths, that some parts of the system can be way busier than others.
Since the stock service is used by the sales, production, and purchasing services it's probably a lot busier than any of those other services.
What Service Fabric (or Kubernetes) can do for you is scale up a couple of extra instances (on different servers if need be) of the stock service if the load is heavy and scale them down when the load decreases.
Service Fabric also takes on the role of a load balancer in that case.
Another benefit is that if you have multiple instances on different servers you can update a server and still have at least one instance of a service so a server update has no downtime for your applications.
And, of course, the same goes for deployments, no downtime whatsoever
|
|
|
|
|
Forgot to look on CP, there's an interesting article: Azure Service Fabric demo[^]
"Why don't you go where fashion sits, putting on the Ritz" 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
