> We should do exactly what the OP says because that's the whole point of news outlets.
Not really. The whole point of news outlets is to provide information for you to process. It makes no sense to leave out any objective reasoning from the task to jump into whitelisting or blacklist entire publications based on whether you were able to point any random issue somewhere in the past. Either the information is valid or accurate, or it isn't. It makes zero sense to claim that the work of author X should be blindly ignored just because you found an issue with a single piece written by author Y years ago.
> this is your criterium, sure. That's nice and simple and for much the same way that physics cows are perfectly spherical
Ironically your example is a good one, because tools like Kubernetes are what enables the proverbial cows of deploying services in heterogeneous clusters of COTS hardware to be interpreted as being spherical in the sense that they are only contained processes that execute somewhere.
And the irony is that you might seriously argue that being forced to waste time modeling cow in higher detail than a sphere is necessary or even required.
> Meanwhile grown-ups still have "monoliths" connected to something like Oracle, DB2 or MS SQL server, because that's obviously the most reliable setup.
More often than not they just crystalized their 90s knowledge and just pretended there aren't better tools for the job because it would take some work to adopt them and no one notices it in their work anyway.
> Adding an entirely new instance is not the only way to accomplish each of those things. A lot of those things can be treated just like applications.
That's what containers are. Containers are applications, packaged to be easily deployable and ran as contained processes. That's it.
Kubernetes is just a tool to run containers in a cluster of COTS hardware/VMs.
I've said it once and will say it again: the testament of Kubernetes is simplify so much the problem of deploying and managing applications in clusters of heterogeneous hardware communicating through software-defined networks thay it enable clueless people to form mental models of how the system operates that are so simple that they actually believe the problem is trivial to solve.
> I think I have said this at work a few times but might have here as well: if nginx or haproxy could natively talk to Consul for upstream data, I’m not sure how much of this other stuff would have ever been necessary.
To be fair, half of the API Gateways and edge router projects out there are basically nginx with a custom consul-like service bolted on.
> Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts
I don't see the point of your post, and frankly sounds like nitpicking.
Ansible is a tool designed to execute scripts remotely through ssh on a collection of servers, and makes the job of writing those scripts trivially easy by a) offering a DSL to write those scripts as a workflow of idempotent operations, and b) offer a myriad of predefined tasks that you can simply add to your scripts and reuse.
Sure, you can write shell scripts to do the same thing. But that's a far lower level solution to a common problem, and one that is far hardsr and requires far more man*hours to implement and maintain.
With Ansible you only need to write a list of servers, ensure you can ssh into them, and write a high-level description of your workflow as idempotent tasks. It takes you literally a couple of minutes to pull this off. How much time would you take to do the same with your shell scripts?
The problem of infrastructure is that low level interfaces are always consumed by higher-level interfaces.
And if you want to run a process, but you want to distribute the apps and run them as process containers, and you want to run them in an automatically configurable cluster of COTS computers communicating through a virtual private network...
Don't you understand where and why are there abstractions?
If anything, having people naively complain about how things are layered and abstracted is a testament of the huge success of the whole teck stack, because complainers formed such a simple mental model of how to distribute, configure, run, and operate collections of heterogeneous services communicating through a virtual network that they simply have no idea of the challenge of implementing a workable system that does half of this.
But with docker+kubernetes it only takes a click, so it must be trivial right?
> was starting to move things to Kubernetes, when it had absolutely no reason to
There is "absolutely no reason" to use a system that automatically handles blue/green deployment of your containers for free and supporting auditable and revertible deployment histories?
I'd like to hear what you consider to be operational best practices!
Hi thanks for mentioning your project. Are there any plans to use it for automated UI testing for desktop apps? Selenium supports it (more or less) with WinAppDriver, which is another project from Microsoft.
> So let’s look at the raw marketshare. It’s 10% of AWS.
Yes, AWS is 1st. What's your point? Azure is 2nd and GCP is currently 3rd and catching up with Azure. What does AWS has to do with whether GCP is 3rd or 4th?
> Google is far from the world’s “third largest provider”
You're being a bit disingenuous. Your own source states quite clearly that Google is in the 3rd spot and arguably, if you cherry-pick results, you can place it in 4th.
By cherry-picked results I'm referring to posting 2018 results and ignoring how GCP's revenue doubled in the last 18 months, nearly matching Azure's revenue.
That only means that the team's head is on the chopping block. That's all.
> 2) How Google treats all of its other "underperforming" products.
This assertion is utterly absurd as you're describing the world's third largest cloud provider, and thus one of the dominant players, of being "underperforming" and justifying pulling the plug on a 8 billion-dolar a year business.
> Because UML is generally about defining processes
It really isn't. In general UML specifies diagrams for relevant system views, but it's centered around diagrams that represents the structure of software projects, not processes. Perhaps UML's most popular diagram is the class diagram, which is complemented with the component diagram and deployment diagram. UML modeling software focuses mostly on structural diagrams, whether to generate source code or dump DDLs. Most of the diagrams used to directly or indirectly represent processes, such as sequence diagrams and communication diagrams, are hardly known and far from popular. Flow charts/activity diagrams are hardly seen as UML, and UML doesn't even provide anything similar to the age old data flow diagrams.
> The difference is that you can't really use proper UML to quickly explain something on a whiteboard, unless you were fluent in it.
That's not true. Class diagrams are boxes with arrows, and so are component diagrams and communication diagrams and deployment diagrams.
If you can draw a box and lines on a whiteboard, you can use UML on a whiteboard.
AFAIK, the only thing that's not explicitly supported in UML is data flow diagrams (i.e., convey the data perspectice instead of describing software components and their interactions).
Not really. The whole point of news outlets is to provide information for you to process. It makes no sense to leave out any objective reasoning from the task to jump into whitelisting or blacklist entire publications based on whether you were able to point any random issue somewhere in the past. Either the information is valid or accurate, or it isn't. It makes zero sense to claim that the work of author X should be blindly ignored just because you found an issue with a single piece written by author Y years ago.