There is no one size fits all

There is no one size fits all

Admin aaTuesday, May 19, 2020

Everybody knows there is no Silver Bullet. We all know there is no one size fits all, however, we still look for it. It happened over and over and for sure will keep happening. Before when there was SOA, people were doing SOA wrong and want to fix all problems with ESB. So there was the SOA Rest Guerilla movement; Let's stop adding things on ESBs and move all to services. Now everybody has coded into microservices, they have distributed monolith in most cases and people are considering removing things from microservices and moving to Kubernetes. Why just run stateless code there right? If we can run all the things there like stateful databases, IoT/Edge, BFF, ML. However, there are other computing models. Most of the couples have Virtualization(EC2 on AWS), Containers (ECS/EKS on aws), Edge(Lambda on Edge for AWS), Serverless(AWs Lambda).

The history repeats: Over and Over again

There are workloads that could fit well on kubernetes others don't. There will be always use cases that will change drastically at scale and there all sorts of different problems and requirements. A long time ago there were JEE(Java Enterprise Edition - also called J2EE back on the days) people did the same mistake lets run all the things there. As you can see, we always know that there is no silver bullet but we still are looking for it. So At the end of the day, it's about balance. We still did not get this lesson as the IT industry. Distributed systems imply that there is no single system.  No Single runtime time, No Single box to add all the stuff. Some problems can be fixed at the platform level with Kubernetes / Istio. However not all the things run on Kubernetes and they should not all run over there. Lyft Envoy is growing a lot on mobile(proxy/lb). There is a need for more distribution with frontend(runs on people browsers), Mobile (runs on people cellphone), Edges Computing(Runs close to people locations for latency reasons). For operations, it is much easier to run all the things in one place. However, this is much more limiting. So If technology is changing and these are the same issues, why they keep coming?

People Problems

Often people consider this "one size fits all" issue a technical problem. We are in 2020, I dont think thats the case anymore. IMHO it's all people's problems, for different reasons we might get different problems but the common denominator is people. IMHO the forces which make this problem happens are:

1. Technology is not about sports: People end up supporting technology like they support football/basketball teams. We cannot provide unconditional love to technology because it blinds us. Technology should serve us not the other way around. Every 5-10 years everything changes. So there is no sense in having unconditional love and basis for temporary tech. Most of the tech is temporary.

2. Lack of Architecture / Design Skills: Lots of companies consider to have an "Architect" a dysfunctional thing. Because you have a team, the team can take care of the architecture, right? If you have a great talent pool maybe but in practice even with great talent pool there are still very poor decisions in a sense of design and architecture.  Because it requires thinking, compiling, and deliver code into production is great however it does not guarantee great design/architecture in the long run.

3. Lack of talent shape decisions: Management often gets afraid of engineers doing some activities, which makes a sociological effect of moving too many things to architecture/infrastructure and components that should not be there end up there because of the talent concentration in DevOps, Architecture and infrastructure teams.

4. There is no Turning back effect: Software allows change. Even poorly architected and poorly designed. However, it's very hard for management or business to pay the price of refactoring. For service industry projects often ends after you deliver them in production. For product companies, there is always a bigger priority so things get "final" and "fixed" easier than you think.

5. Knowledge gravitates towards people to companies: There is no such thing and "company" knowledge. There is only people's knowledge. IF you can retain and attract amazing talent with Architecture / Design skills the problems will keep happening over and over. Even worse because your company anti-buddies will fight "different" ideas for lots of the wrong reasons like Fear, Job Security, Ignorance, Power, etc. Some companies are worried about losing talent but they are no worries with the "debt people" they are keeping. Great people end up leaving, sooner or later with makes the problem keep happening.

The bottom line

In my previous blog post, I was talking about the Death of the microservices due to the rise of distributed monoliths. You might be wondering that this is 2 completely different subjects right? Wrong. It's all the same thing. IF we are doing wrong by moving all the code to shared-libs by side-effect creating a distributed-monolith and killing microservices. The solution cannot be "move all the things to Kubernetes or Platform" because we will have the same issue.

Lack of talent and education are shaping our bad decisions. Principles are more important then ever, however, if you dont have enough people who care about it and execute than well. You won't get a proper architecture and will fail by coupling one way or another.

Running Istio 1.5 on Minikube

Running Istio 1.5 on Minikube

Admin aaSaturday, March 14, 2020

Istio 1.5 is out. Istio took a very bald and big move. Istio decided to move away from microservices. Considering istio use case it makes lots of sense. As you go with microservice architecture you have several advantages like autonomy, use the best tool for the job(different languages), scale components independently, isolation and many others. However, microservices are not a free lunch and there is a downside from it. One of them is the DevOps engineering price to configure, provision, monitor and maintain several isolated services. The other one is complexity. Microservices are more complex than monolith systems. Istio took the move and went to from the microservices architecture with 5 services(Pilot, Cidatel, Telemetry, Policy, Galley, Injector) into 1 single service called istiod. This move made lots of sense.  Not only because it removed complexity but also make configuration, installation and upgrade much easier. I',m sure this move will drive more adoption.

Running Istio 1.5 in Minikube



There are some important things to keep in mind. First of all, I'm setting up 16GB for istio. Istio runs much better with more memory. It's possible to run it with 8GB if you like. If you are having issues, for sure is the memory. Crash loop back in Kubernetes most of the time is because of the lack of resources like memory.

Secondly, there are some commands that will require you to open new terminals like the minikube tunnel and dashboards. Keep in mind some of the dashboard commands like envoy and controlz require the pod name which will change, so do a kubectl get and pick the right pod name. Keep in mind istio is deployed in a different namespace called (istio-system) in order to access it via kubectl you need to pass -n istio-system at the end of each command.

Here are some screenshots of Istio 1.5 running on my machine.

kubectl get all (show all resources from the demo app)

kubectl get all -n istio-system (show all resources from istio namespace/installation)

istioctl dashboard kiali (show kiali service-mesh graph visualization of the demo app).

istioctl dashboard Prometheus (show Prometheus observability ui).

istioctl dashboard envoy $productpage_pod_name

istioctl dashboard controlz $istiod-pod-name -n istio-system

Product Page demo app running on my chrome

istioctl dashboard jaeger

istioctl dashbaord grafana

Istio 1.5 it's very sexy. One of the biggest downsides of istio just got fixed(complexity of configuration, maintained and upgrade). The only thing we still need to be paying attention to is overhead.  The last time I check was around 10ms. I'm sure istio will get faster and better.

Cheers,
Diego Pacheco

Running a rich Microservice constellation in Kubernetes

Running a rich Microservice constellation in Kubernetes

Admin aaWednesday, March 11, 2020

Languages have trade-offs like any solution in tech. Microservices are great for many reasons, one of them allows the best tool for the job. Kubernetes allows us to have the same operational standards and procedures even using different languages and solutions. For this blog post, I want to show a simple project I build which is a constellation of services. There are 5 microservices, written in several languages like Scala, Java, Go, Python and Rust. The services do a pretty basic math operation like (+, - , / , *) and the Scala one does the aggregation and orchestrate the other services using a polish notation algorithm and REST calls.

The Video



Calc Services (5 Microservices Scala, Go, Rust, Python, and Java) running on K8s from Diego Pacheco on Vimeo.

The Source Code

The complete source code is here on my github.

Cheers,
Diego Pacheco

Running Rust Service in Kubernetes with only 3.5MB

Running Rust Service in Kubernetes with only 3.5MB

Admin aaMonday, September 23, 2019

Rust is a very exciting language. Not only for system programming but also for microservices and business development. Today I will show how we can create a simple service application in rust using Iron Framework. For this blog post, we will build a rust binary and run both in Docker and Kubernetes. In order to run kubernetes locally, I will be using minikube but you can use any kind of kubernetes cluster or distribution and it should work just fine. The most amazing thing is that we can build a rust executable with only 3.5MB and a docker image with the only 3.63MB. This is super lean!



Talk is Cheap, show me the Code!

Here we go.  Behold the main.rs file.

Here we are using Iron Web Framework and also ust env utilities in order to access OS level Env variables. The server is running on the port 8080, there is a function called hello_world with revices a request from icon a returns an Iron result with a Response. Inside the function I'm defining a key, which is a simple string that represents the env var I'm looking for, in this case, called: RUST_SVC_VERSION. After that, I'm using env_var_os to check if the var is present, also using the good rust pattern matcher to see if their var is present or not. IF The var is present I will receive Some otherwise none. In the case that the var is empty I'm returning an undefined version of the app on the response otherwise I return the value of the var concatenated with the String Hello World! V:.

We need to declare an Iron dependency in Cargo.Toml file.



Now Let build our Rust application, we will use docker to build the app, we do this way. Let's take a look at release-rust.sh file.

Here we are using rust builder in order to build the binary in an optimized way. Now we can take a look at the Dockerfile.

As you can see the Dockerfile is dead simple, we just add 1 file, which is the binary we just built and we expose the port 8080. Call the binary as main CMD from Docker and that's it, folks. Let's bake this docker image doing:

Now that we build it, we just need to run it. Let's run it by doing:

As you can realize here, I'm passing an env var to docker, with version 1, feel free to change the value and see that it works.

Let's run it with Kubernetes now. Let's take a look at the deployment and service specs.

For the deployment yaml file (^^^) as you can see we are using my docker image we just built. This image is also in my docker hub, so thats why you dont need perform any craziness to run in your minikube :D

Now we have the service yaml file (^^^) keep in mind we dont want use ClusterIP in production folks this is just for development and fun.  Having this 2 specs, we can create a folder called specs and we can deploy them to kubernetes using kubectl.

After the deploy, we can expose our service via port-forwarding and then we can call it :D

In the script above I'm using kubectl to select the pod I want using selectors, a great feature from kubernetes, I'm getting the name of the pods with the app==rustapp. Them storing this result in a bash variable and calling kubectl port-forwarding on this pod. I'm binding container 8080 port to my 8080 local port. That's it, now you can just do: curl http://localhost:8080/ and you will see it works.

Here is the complete source code in my github.

Cheers,
Diego Pacheco

Microk8s

Microk8s

Admin aaSaturday, April 20, 2019

Microk8s is another lightweight k8s distribution - perfect for local tests, an interesting alternative to Minikube, k3s, and Kind.  Microk8s works smoothly in 42 flavors of Linux(Geek Moment: You know is the right answer when you see the number 42. LOL. ).  Microk8s has easy install and several interesting features like Local Storage, Dashboards, Metrics, DNS, Ingress, Istio and much more.

Zero Ops needed with a single k8s cluster done right. That's the marketing of microk8s. In practices, the product works very well but I found a bit slow(start and stop). However installing istio, is 1 command line away from happiness.  Microk8s supports several versions of Kubernetes from 1.10+ to 1.13+ right now(20/04/2019) - k8s is 1.14+.  If you are a hardcore Linux user you must try mcirok8s.




Running Microk8s on Ubuntu



Cheers,
Diego Pacheco

Kind - Kubernetes in Docker

Kind - Kubernetes in Docker

Admin aa

Kind - Allow us to run Kubernetes in Docker. This is not a production-ready solution - however, has a lot of potential in order to make a safe and lightweight alternative option to Minikube.  Kind is built with Go and uses Docker API in order to get things spinning.
I got impressed with the speed thing runs with kind, this is an interesting alternative together with k3s and Minikube.




Getting Started with Kind



Cheers,
Diego Pacheco

Using Multiple profiles with Minikube

Using Multiple profiles with Minikube

Admin aa

Kubernetes is the new Linux. K8s is the spec for the multi-poly cloud world. Running k8s could be very resource intensive, so is always a good idea being able to run things locally. For several reasons like Engineering Productivity, Tests and Experiments and so on and on. If you are working with Istio like I'm, you might realize it's a bit heavy to run local, especially if you do have other things running on k8s.  Minikube is the goto solution for local kubernetes clusters. However, as I said before, it can get pretty heavy when Istio gets involved. So the solution is pretty simple, it not much advertised. Minikube has a profile feature which allows you to create multiple profiles. Each profile will be a 2GB DISK VM created in Virtualbox. This is great because now you can run multiple kubernetes versions and multiple clusters doing multi experiments. IMHO is always great to have a k8s cluster ready to test things so I have multiple profiles like istio, lightweight, tests, etc... The first time you create the profile takes some time, up to 10min worst case but after the profile created things are super fast.

Running Multiple profiles with Minikube



Cheers,
Diego Pacheco

Kubernetes Everywhere with k3s

Kubernetes Everywhere with k3s

Admin aaSunday, March 3, 2019

Kubernetes is becoming the truly cloud-native specification for the cloud. However not all software runs on the cloud, there are other uses cases like embedded software(IoT and microcontrollers) besides IoT there is another kind of computation that is growing more a more nowadays called Edge, thanks to the low latency and facility capabilities. Would be great run the same infrastructure for the edge/IoT as we do for the cloud? Well, rancher folks addressed that with k3s. A super lightweight kubernetes distribution where they replace things and remove features instead of adding, This is great not only for the IoT/Edge uses cases but also for folks who study the cluster in the academia and for the developers in 2 fronts. First on the CI/CD front, so we can spin up a lightweight cluster to run all kinds of tests, this also has a perfect fit with GitOPS model.

Another developer use case is the local machine scenario. For developer is very important to have a set of lightweight solutions, so they can run on the local machines this is important for a lot of reasons like:

• A sandbox to play and do experiments
• Learn effectively
• Debug and Troubleshoot
• Simulate some kinds of bugs in order to add tests

Not all scenarios can be covered with the local environment and that does not kill the need to have a cloud environment for development. However, this is a powerful tool for the developer and speeds up things a lot. 

Running k3s Locally

k3s is super lightweight and super fast. The solutions are pretty new but have lots of potentials. There are some limitations in k3s like there is no ALPHA specs support.

Running the Server

Echo App Spec



Get Pods

Running a service in kubernetes using k3s

cheers,

Diego Pacheco

Istio & Kubernetes: Developer Productivity and freedom to deliver your OKRs

Istio & Kubernetes: Developer Productivity and freedom to deliver your OKRs

Admin aaThursday, February 14, 2019

Innovation is a must have for companies today and work with the product mindset. Given the digital transformation, we live in, having a product mindset is more than delivering software but it is empowering teams and working with OKR-based management models that focus on Business Objectives rather than what teams have to do.

Development teams are motivated by challenges and they should have the freedom to make choices. But these choices can often have a very high cost for the business and low return. Cloud usage is certainly a great disruptive force for all digital businesses. 

There are many ways to architect Cloud-Native solutions (get the most out of cloud) often for a short-term view many companies are opting for Managed Services solution. These solutions, which are often database solutions, but not limited to the database, give a lot of speed for software development but bring two major problems in the long run.




Managed Services Issue 1 - Cloud Vendor Lock-in

When using managed services there is a cost reduction and bottleneck of DevOps, which is a difficult skill set to hire. However, when using managed services proprietary APIs, you are certainly thinking that you are taking a lot of value out of your cloud vendor, based on usage. Using 100% of a service does not mean better value for the business. In the long term it costs more but often these decisions are taken by lack of software architecture knowledge to support in making the best technical decision.

Managed Services Issue 2 - Cost

Increasingly there are more and more cloud providers and the cost is more and more a central issue not just for software architecture but for the business as well. It is necessary to have solutions that are COST-EFFECTIVE but often this math is made only considering the initial cost of OPS that the cloud provider absorbs. But in the long run, it is much cheaper to run this kind of solution on Compute layers than to run as a managed service. However, when using computer solution many times it is necessary to perform many integrations and development of cloud-native architectures to enable digital products. Soon this equation becomes complex and once again it is common for companies to tend to managed services for cost reduction and simplicity of execution even if this sacrifices portability in the long run.

Istio & Kubernetes: Changing the Rules of the Game

The Market changes fast, nowadays we no longer need to choose between productivity, low initial cost, and profitability because with Kubernetes and Istio we can have the 3. That same we can have the maximum of productivity giving total freedom for the technical teams, low cost of ramp up and still be portable to work multi/poly cloud solution.

With Kubernetes and Istio it is possible to develop microservices in a disconnected form of any cloud provider. Because Kubernetes in conjunction with Istio and Envoy (Lyft's open source proxy solution - Uber Concurrent Us) uses the kubernetes abstraction translation service for the cloud provider. That way your solution is not stuck with any specific cloud vendor.

There are solutions to create, run, update, maintain and destroy kubernetes clusters of in multiple clouds like AWS (Amazon) and GCP (Google) like Kops. Kops is an open source software that does all this for us still being able to generate Terraform templates for the translation of specific solutions from Google's cloud(GCP) or AWS. For example, in Kubernetes there is the concept of gateway that is used for transfer data and with Kops, this concept will be translated into an Elastic Load Balancer (ELB) in AWS for example.

Why Use Istio?

Istio allows the developer to use any language and any server. There is no such thing as a binary coupling as there was in the NetflixOSS Stack that forced the use of Java and a series of intrusive dependencies in the classpath. With Istio we have the same abstractions that exist in the NetflixOSS Stack but at the platform level, thus leaving the very productive developer and much more focused on business, digital products, without losing all the benefits of a cloud-native architecture.

Business Benefits

By using Kubernetes and Istio the business can deliver digital products with extreme productivity and at the same time not be locked-in by cloud vendors. So in the future, if the business realizes it more economically viable to migrate to another cloud-provider this is possible in a transparent way. In addition, it is less sensitive to the cloud provider's cost variations and has the strategic freedom to go where it makes more sense and has the best cost.

There is another great benefit that is in the motivation part of the technical team that helps keep the professionals motivated and the turn-over low because that way the technical team can try out new servers, new languages independently and delivering value to the business. Engineers are motivated by challenges and new technologies, often tied systems do not allow experimentation what is bad for the motivation of the technical team as well as experimenting with new technologies to solve problems and create new business models. With istio, everyone wins.

For the Devops Team

Creating digital Stacks in the cloud is not a simple task and is expensive. Often the Devops team is under-resourced and cannot keep up with internal demand. The solution to this problem lies in, building and releasing tools for the developers to be more productive. Building self-service tools and services and thus freeing the Devops team to focus on improving tools and availability of digital products.

Solutions such as Kubernetes, Kops, and Istio help to remove a lot of manual work from the business engineer and thus deliver a high-profit stack to the business with little effort. Istio provides a complete solution with Observability (Logs, Metrics, Traces) of the entire Kubernetes stack.

For Developers

In addition to being able to use any language at the end of the day is not bound to the decisions that come from above and is free to reach the OKRs in the best way they understand besides having the possibility to experiment new technologies of easy integration to the stack of existing services. Another advantage is that with the setup time fast and complete isolation is very simple to have more environments and debottleneck platforms teams to release components.

Kubernetes and Istio have great potential and this is just the beginning of the journey. If you are doing digital transformation or starting a new project you need to consider this solution as it has many advantages compared to previous approaches of First Wave of Microservices with Stack of NetflixOSS, ManagedServices using proprietary APIs of cloud providers. We are actually talking about something that is "Game Changing" for the business and for the technical teams.

Cheers,

Diego Pacheco

Kubernetes 101

Kubernetes 101

Admin aaTuesday, February 12, 2019

Kubernetes has lots of concepts. It's easy to get lost in the middle of all core concept the project has. However, all these abstractions provide a great benefit which is the standard spec for different kinds of services and workloads. IF cloud providers were born with a common spec/API, we would not be talking about this subject now a day, unfortunately, this is not the reality. Today I want to share a simple presentation I made trying to explain the many concepts present in kubernetes and how they differentiate between each other like what's the difference of a Secret vs ConfigMap or how ReplicateSet is different compared with a Deployment. Also, cover what kinds of service are available and when to use ClusterIP vs Loadbalancer for instance. You will also see GitOps model, which the standard k8s way to work in production.



Kubernetes 101

Slides

Kubernetes 101 from Diego Pacheco

Video



Cheers,
Diego Pacheco

Running k8s on EKS

Running k8s on EKS

Admin aaWednesday, February 6, 2019

EKS is the new AWS managed Service for Kubernetes launched at last Re-Invent 2018.  EKS is not available in all regions right now. EKS an option for those who don't want to use KOPS.  For this blog post, I will show how to easily set up a kubernetes cluster in AWS using EKS.  EKS has some benefits, first of all, is a managed service that you are not locked in since the API is kubernetes based so you can easily migrate to other kubernetes installation or even other kubernetes installation in other cloud vendor or on-premises.




EKS Benefits

• Managed Service without lock-in (Kubernetes API, specs, kubectl)
• There is no Control Plane management (Multi-AZ, Automatic patches, and updates)
• Secure by Default (Secure and encrypted communications between worker nodes and master)
• Conformant and Compatible (EKS runs certified kubernetes. Compatible with standard k8s envs)

IMHO this is what most of the companies are looking for, in other words, *Serverless*. 

The Pain Points

I don't want to paint a rosy picture of EKS like any new technology there are problems such as:

• Poor Documentation - very few docs
• Lack of Observability - It's a kind of black blocks compared with Kops.
• When you do something wrong and har to figure it what you did it wrong.
• Error-Prone - Is very easy to make mistakes(eksctl fix that)
• In a Long Run is more expensive than running on EC2 with Kops
• Alpha APIS is not supported. 

It's important to keep in mind that EKS is a very new service and it should get better and the time passes. 

Running Kubernetes in EKS using EKSCTL

EKSCTL is a great tool. Written in go, makes eks cluster creatin way less error-prone and many simples to get a cluster up and running. So let's get started! Basically, we will install the AWS Authenticator and EKSCTL them we can create the cluster and deploy nginx in kubernetes after that we can access the nginx application in the browser(before that you will need to enable the SG access for your IP). Them we destroy the cluster.

Creating a cluster

 Deploying nginx in Kubernetes

Nginx up and running on AWS(Need to enable 80 port SG access)

















Nginx AWS ELB Created by EKS and K8s with EKSCTL

 K8s Nodes Running on EC2 via EKS and EKSCTL

Destroying the cluster

Cheers,

Diego Pacheco

Running Istio on AWS with Kops

Running Istio on AWS with Kops

Admin aaTuesday, February 5, 2019

In previous posts, I show how to run Istio in Minikube and with Docker-Compose/Consul in local env, today I will show how to run on AWS using KOPS.

This installation is Linux based(Ubuntu), I'm running all commands from my local-desktop, if you don't use Linux(shame on you) you can create a virtual-machine on AWS with ubuntu and run this commands there, also is possible to run Vagrant with Linux and them run this commands on Vagrant box as well. Istio runs smoothly in AWS with Kops. You don't need much, pretty much 3 machines(1 master node, 2 minions).  Keep in mind this is not a production-grade setup, for production, you should be running with 3 masters at least for High Availability.




Installing and Running Istio with Kops

Master and Worker nodes on AWS EC2 Console

Istio Metrics in Grafana

Jaeger - Distributed Tracing

Kiali - Observability

















BookInfo ServiceMesh (4 microservices) running on Istio / Kubernetes in AWS

Prometheus(Cloud-Native Observability) - Metrics, Dashboards, and Alerts 

ServiceGraph

That's it - I hope you enjoyed.

Cheers,
Diego Pacheco

Running Kubernetes on AWS with KOPS

Running Kubernetes on AWS with KOPS

Admin aa

Kops is the best way to have Kubernetes running in AWS. Kops allow us to install kubernetes in EC2. Kops is written in Go. Kops helps us to create, update, maintain and destroy kubernetes clusters on aws. Kops also supports GCP(Google Could Platform). Kops has some interesting ability to generate terraform files if that's your you thing :-).  For this blog post, we will be using AWS ELB as DNS so we won't be using public DNS records which are done by setting carefully the name of the cluster - which need to end with .k8s.local. Right now is way faster to spin up a kubernetes cluster with Kops rather than EKS.



Installing and running Kubernetes in AWS with KOPS



Cheers,
Diego Pacheco

Why do you need Kubernetes in your next project?

Why do you need Kubernetes in your next project?

Admin aaWednesday, December 19, 2018

The cloud is not the end, but the beginning. Starting a quick journey to the cloud brings benefits to your business. However, to get more benefits and reduce costs it is necessary to adopt a cloud-native mindset, which means going beyond, using the maximum value of cloud computing.

Kubernetes, a system designed by Google and maintained by the Cloud Native Computing Foundation, for example, is much more than a container orchestration solution. Many experts consider Kubernetes the new Linux since much evolution is to happen in this system.

Nowadays all organizations use Linux, but not all organizations use Kubernetes. Possibly we will reach the point where all companies will start using kubernetes, just as they use Linux today. You must be imagining technical reasons for using Kubernetes. They exist and there are many, however, there are also very relevant business reasons regarding the use of this system.

Keeping Innovation Flowing

It is increasingly important to innovate within companies - corporate innovation - but this innovation is very difficult and has several challenges. Within enterprise innovation, it is necessary to integrate existing software quickly and also to discard solutions and ideas quickly. Kubernetes accelerates this time by reducing operational load, which is the bottleneck in many companies.

Focus on User Experience

The user is at the center of everything we do - or should be at least. However, the user experience is not just "look-and-feel" or "how" things work, but also "if" they work. Many solutions are architected as a house of cards in which the first error causes several other features to be affected. With Kubernetes it is possible to maximize the isolation of features and reduce the impact spectrum when something goes wrong as well as reduce recovery time.

Portability

Nowadays nobody thinks about losing the phone number or WhatsApp. In the past, if you wanted to switch carriers - for better or cheaper service - you would lose the number. Nowadays there is number portability. Kubernetes is one of the solutions that enable the portability of cloud-provider - Google, Amazon, Microsoft, and others. This portability is already real and used in solutions like WAZE - Using Spinnaker.

Maintaining Business Value

From time to time it is very common in IT industries to have the need to re-write a number of ZERO applications in view of better architecture and more robust solutions. With Kubernetes this need is less, since its solution is more portable and, consequently, the erosion of the business value becomes much smaller. This process allows your business to be ported without having to be rewritten.

Maximizing Value - Large Uses Case Cover

Kubernetes is not only for backend solutions, but it is also possible to run machine learning (ML) and Big Data workloads using Spark, for example, and more. In addition, there are many other Serverless frameworks on top of Kubernetes, such as Google knative.

Strategic Freedom and Cost Reduction

With the possibility of portability, it is possible to run solutions in 1 or multiple clouds, thus taking the maximum value from each supplier, and can also migrate to other clouds when the cost becomes more interesting. This way, your business stays in a strategic position rather than being held hostage by cloud providers.

Time to Market Reduction

One of the principles of modern innovation through Lean Startup is to reduce time to market, that is, to put ideas and solutions out faster. Kubernetes helps us with this because through the system we can have shorter deploys cycles with less infrastructure overhead.

Your journey to the cloud should not stop after Lift and Shift. Kubernetes is much more than a container orchestrator. If you do not want to make another digital transformation in 5 years, it is very important that you consider Kubernetes as a very strategic solution to your business.

Cheers,
Diego Pacheco
https://diegopacheco.github.io/

Building Effective Microservices - 80% OFF until 30th November

Building Effective Microservices - 80% OFF until 30th November

Admin aaFriday, November 10, 2017

Want to learn how to build microservices using Java 8, NetflixOSS Stack(Eureka, RxNetty, Feign, Hystrix, Ribbon) using Kubernetes(Minikube). 

That's the real deal you read it right. Get my videos series: Building Effective Microservices 80% until 30th November 2017.