May 20, 2024 at 12:00 am
Comments posted to this topic are about the item Kubernetes is Cool, But ...
May 20, 2024 at 8:52 am
Totally agree. There are a number of technologies that data people use directly or indirectly that I feel I want to consume rather than administer. I also feel your comment about whether everyone needs the technology and the complexity that comes with it is also important. On an architectural diagram it all makes sense. In the real world there are a lot of costs and pain points with those solutions.
I had to use Apache Airflow to orchestrate the flow of data jobs. Thankfully in its guise of Google Composer. I started to look at installing Airlflow locally, mainly for offline development and working out ways of testing DAGS. I realised quite quickly that Apache Airflow is quite a big beast too, though relevant to data engineers.
I feel that the phenomenon is not a new one. Nearly 2 decades ago a development team proudly demonstrated their implementation of Apache Solr. When I looked at what was being done with Solr it was nothing you couldn't do with a basic SQL Server Full Text Search. On the architecture diagram for the solution there was a box for full text search and because that box existed it was interpreted as as need for a discreet full text search product and not a full text capability that we might already have as part of our licence.
May 20, 2024 at 12:20 pm
Offloading containers and container orchestration is a major part of “cloud native”.
With Azure, you specify the scaling and redundancy (and the attributes for them) with app services, databases, etc. Microsoft handles (under the covers by automation) the containers and orchestration to meet the contractural requirements of the settings you make.
No one in your organization needs to spend one minute (think $$$ times minutes) on setting up, maintaining, and adjusting containers and orchestration. Microsoft is accountable for meeting the required performance.
I am pretty sure AWS, Google Cloud, and others provide similar “cloud native” functionality.
If you are in the cloud, managing your own VMs, containers, orchestration, etc., you are using the most “total cost” expensive cloud option - “cloud hosted”.
Going “cloud native” is almost always a significantly lower total cost of ownership over the lifecycle of your system than “cloud hosted”. Scalability, reliability, ease of deployment, and total cost of ownership will almost always be better in your favor with “cloud native” than with “cloud hosted”.
May 21, 2024 at 9:21 am
Kubernetes is indeed complex to setup and maintain. That's why except the odd containers we work with vm's on-premises.
The cloud can handle that complexity better behind the scenes.
May 21, 2024 at 3:06 pm
I find a lot of people struggle with it. I think many even struggle with too many containers/apps, either on servers or laptops. Often 1-2 work good, but trying to spin up too many gets too complex.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply