I'm confused with cloud/clustering technologies like Docker Swarm and Spring Cloud and how they relates to each other.
Is it correct way to thing, they implement same functionality at different layers? For example docker swarm performs load balancing and service discovery at container or network layer (application is agnostic of this layer), where as framework like Spring Cloud embeds this logic to application, giving more flexibility, but also violating separation of concerns.
Am I mistaken, or is this correct? What is the SWOT of each approach, and is there any reason to use both Docker tooling and Spring Cloud utilities together?
First off, Spring and Docker are two different technologies coming from different points of view. From what I can gather, Spring Cloud is a mechanism for deploying java containers and orchestrating them.
Docker is an application / OS agnostic deployment mechanism.
I don't know much about Spring Cloud, but if you're in an environment that is not all Java, it may make more sense to approach Docker. It would allow you to deploy micro services on just about any platform.
We went through this at the last company I worked for, as they were implementing Springboot, but also looking at Docker at the same time. In the end it just made sense to deploy everything in Docker since it provided a uniform deployment and service management mechanism. That as opposed to hobbling together various deployment and management tools by language.
Related
I have some questions about terminology that I should use. I have searched up the components that I am using, but I am still not sure. Can you please check if these are right way to describe each component? If not, can you please revise it?
I develop microservices using Spring Framework (Spring boot).
I deploy components on cloud via Kubernetes and Docker. (I understand Docker is used for containerizing and Kubernetes is for orchestrating multiple containers. Is it right to say "I deploy on Kubernetes or via Kubernetes"?)
CI/CD pipeline using Jenkins and Azure DevOps. (Project uses Azure DevOps for triggering CI/CD in Jenkins)
Please note that this project was already there when I joined the team, and I am new to all of these concepts. I understand what they do briefly and I know what each terminology means on entry level, but I just want to make sure if I am saying these in right ways.
I would say that you deploy services, not components, but your team might have its own terminology.
You do deploy on Kubernetes.
Docker is used to create and manage containers and container images. Kubernetes does not use Docker but can use images created via Docker to deploy containers in Pods (via the OCI format)
The rest seems right to me :)
In Kubernetes an app as a unit is called Service. It has components reachable under it, for example: deployment, pod, etc. This set of components could be for microservice or service, but terminology just a service.
You can list all services using kubectl get services
The Docker is related here only because pod has a container or sometimes few of them. So Kubernetes supports Docker and its images. It's most popular container runtime in 2021, but not the only one for Kubernetes.
To combine everything, the right sentence to me would be:
I deploy a service on Kubernetes
I deploy a service on Amazon EKS
I deploy a service on Azure Kubernetes
etc.
Adding "cloud" doesn't add so much value as Kubernetes platform is same regardless of cloud provider chosen. Of course, there are some differences in cloud, but not in Kubernetes core.
Docker doesn't fit here and usually discussed when going into details, especially about images, building them, etc.
Also off topic, but even pod is more used than container, because in Kubernetes you access the pod (while in Docker Compose, you access the container). Of course, you can access Docker container if there are multiple of them setup in a pod and container engine is Docker in this context.
I develop microservices using Spring Framework (Spring boot).
To understand in the most basic form - Microservices is an architectural pattern for developing applications, so there can be many ways to implement this pattern (which is nothing but developing applications) and Spring Boot is one of them. More precisely you should say "I develop microservices using Spring Boot"
I deploy components on cloud via Kubernetes and Docker. (I understand
Docker is used for containerizing and Kubernetes is for orchestrating
multiple containers. Is it right to say "I deploy on Kubernetes or via
Kubernetes"?)
Precisely speaking you are not correct here - you understand the purpose of Docker and Kubernetes but putting it wrongly w.r.t. application and its deployment.
Do read this, where it is clearly mentioned that K8s doesn't build or deploy code. When the official documentation is clearly saying that K8s doesn't deploy code, then how you can say that I deploy via K8s?
I would say you shouldn't put it using either of the statement you mentioned, rather you should say - "My application runs (or is deployed) in Cloud on a Kubernetes cluster (or GKE or EKS or AKS)".
CI/CD pipeline using Jenkins and Azure DevOps. (Project uses Azure
DevOps for triggering CI/CD in Jenkins)
Looks fine to me.
Please note that in general you can say anything as long as the other person is able to understand, so in general all your statements might sell well. But I guess you were looking for "precise" statements, and I gave you my thoughts on the same.
Guys here are right but I would like to add that when speaking of Kubernetes components you usually think of Control Plane Components or Node Components and when speaking of smaller units the Services and Pods comes to mind first. Note that a Kubernetes service is an abstract way to expose an application running on a set of Pods as a network service. So addressing your main question:
Is it correct to say I am deploying components via Kubernetes?
It would be better to say that you are deploying a service/application (running) on Kubernetes (on AKS/AWS/GCP/etc).
I know it's a vague question but that's because I am not clear enough on what people are doing to ask anything more specific. I currently run my own apps with the embedded reactor netty server for development and basically push the embedded server inside a jar to cloud foundry to run the embedded server in production.
What are the other ways out there to set up a production environment for reactive reactor netty apps that people are using, or any documentation you might have seen?
I'm no sure that there is any difference between hosting the reactive spring-webflux application and regular applications.
Spring boot creates a jar with everything bundled inside (netty or more old-school tomcat) - it doesn't matter.
Then you can take this and run it "as is" on your server (on-premise, cloud ec2 style whatever you have, this really depends on your organization) directly with java -jar app.jar
Or, if you have more advanced needs/setup:
"Containerize" the application and create a docker (usually, although there are alternatives) image that runs the spring boot application. and then deploy it on kubernetes cluster, for example. At this point you should really consult with your DevOps people so that they'll tell you what is the way of deployment in your organization.
Besides kubernetes cluster there are many other alternatives:
- cloud provider specific solutions, like ECS or Fargate in amazon AWS
- Docker Swarm to name a few
All these solutions are pretty advanced, allow auto-scaling, advanced liveness monitoring and so forth. As an organization you usually pick the one that meets your needs
I am learning building microservices using spring boot, Spring Cloud(netflix OSS Components). I have used netflix Eureka for service discovery, zuul for api gateway, ribbon, feign while running in my local machine.
Netflix eureka, zuul, ribbon, feign spring cloud config are not useful when we deploy to PCF?(if yes what are the alternatives available in pcf and how to configure them?)
As who are building microservices follows CI/CD approach, how developer verify working of their micro services before pushing code as we don't use eureka, zuul,ribbon,feign in production pcf. (how to simulate pcf environment in developer machine?).
I'd suggest to read below content before implementing if you have any doubt regarding usage of Eureka and Zuul, you will get all answers yourself.
https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
https://github.com/Netflix/zuul/wiki
As who are building microservices follows CI/CD approach, how developer verify working of their micro services before pushing code as we don't use eureka, zuul,ribbon,feign in production pcf.
Answer to this question is: You must be aware of JUnit test cases, so you can run you test cases using deployment pipelines to make sure all your functionalities are working as expected or you can use Test Automation for the same.
(how to simulate pcf environment in developer machine?).
Answer to this one:
You can use eclipse plugin you are using eclipse/STS IDE. Or you can connect all PCF services from you local machine using CloudFactory
#Bean
public Cloud cloud() {
return new CloudFactory().getCloud();
}
https://docs.pivotal.io/pivotalcf/2-1/buildpacks/java/sts.html
Here are some thoughts:
Eureka Service discovery: in my opinion this is not strictly necessary when running on PCF. When you push an app on PCF usually a route is assigned to your app, and you can use this Route as a poor man's service discovery. Eureka would allow you to use client-side load balancing in the case of container-to-container networking, but usually you wouldn't need this.
Zuul: Can be very useful also on CloudFoundry in case you are doing things like writing frontend-for-backend services, providing frontends for different devices (mobiles, desktops, i-pads) that use the same backend services. Might also be useful for an authentication/authorization layer or rate-limiting. One native CloudFoundry alternative would be to use route-services for tasks such as rate limiting, authentication/authorization.
spring-cloud-config: makes sense if you want your configuration to be under version control for different environments. This is useful no matter if you are running on CloudFoundry or not. I don't know of any alternatives on plain CloudFoundry.
spring-cloud-feign: makes sense if you want use annotations such as #RequestMapping with your Feign client interfaces. This is independent on if you are running on CloudFoundry or not. AFAIK there are no alternatives for this in case you want to use Spring MVC annotations with Feign.
ribbon: makes sense if you want to use client side load balancing as opposed to let the CloudFoundry router to do the load balancing for you.
How developers can check locally if this works for them:
In general, I don't believe developers should need to check locally if their app is working fine together with zuul, cloud-config-service, and eureka.
They could check this in a dev or test space or environment though.
If they really want to check this on their local machine, they could download PCFDev and run these infrastructure components there.
Hope this helps.
I'm a newbie on Spring Cloud, and I'm a little confused about it. Kubernetes and Spring Cloud are both micro-services framework. If I have Kubernetes(or mesos) already, why do I need use Spring Cloud? I notice that many projects use them both.
What's the difference between Kubernetes and Spring Cloud? They both can provide service discovery, load balance and so on.
I'm really confused.
Kubernetes and Spring Cloud address a lot of the same concerns with Microservices, but with different approaches and technologies. Redhat wrote a great article explaining this. Here the main takeaways:
Spring Cloud has a rich set of well integrated Java libraries to
address all runtime concerns as part of the application stack. As a
result, the Microservices themselves have libraries and runtime agents
to do client side service discovery, load balancing, configuration
update, metrics tracking, etc. Patterns such as singleton clustered
services, batch jobs are managed in the JVM too.
Kubernetes is
polyglot, doesn’t target only the Java platform, and addresses the
distributed computing challenges in a generic for all languages way.
It provides services for configuration management, service discovery,
load balancing, tracing, metrics, singletons, scheduled jobs on the
platform level, outside of the application stack. The application
doesn’t need any library or agents for client side logic and it can be
written in any language.
In some areas both platforms rely on similar
third party tools. For example the ELK and EFK stacks, tracing
libraries, etc.
Some libraries such as Hystrix, Spring Boot are useful
equally well on both environments. There are areas where both
platforms are complementary and can be combined together to create a
more powerful solution (KubeFlix and Spring Cloud Kubernetes are such
examples).
Source: https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/
To understand the differences and similarities in more detail I would recommend to the read the full article.
I am trying to get the idea of cloud serves but didn't get the point of that.
Dose it can replace a server for the app?
what is the purpose of it?
I have an android app and I what to get info from the server can it be done with Cloud Foundry and what is spring and how it connects to Cloud Foundry.
If you can give me link of how to communicate android app with Cloud Foundry
thanks a lot!
CloudFoundry's an open-source PaaS (github.com/cloudfoundry). It commoditizes the stack - that is, in practical terms, it makes it dead simple to get things like databases (MySQL, PostgreSQL, Redis, MongoDB), messaging (RabbitMQ), and web servers (Tomcat) up and running quickly. Whereas clouds like AWS let you spin up CPUs and hard disks and a stock OS install, a PaaS like CloudFoundry lets you spin up infrastructure, like message brokers, databases, and web servers and routers. So, yes, it replaces a server (or, often more importantly, it can stand in for 1000 servers on-demand). That's the obvious part.
CloudFoundry itself is open source, so unlike other PaaS solutions, by building on top of CF you're not locked into CF. You can later decide to run the cloud locally on your own datacenter, or on some other CloudFoundry provider (CloudFoundry.com is just one provider of the CloudFoundry software. Just as you can easily re-target a git repisotry to have it point to any remote repository using the git command line tool, you can re-target the CloudFoundry 'vmc' command line tool to point to a different CloudFoundry install.
Spring's a development framework in Java. It's not the only way to consume CF, but I personally think it's quite nice. CF exposes a lot of different technologies for the eager technologist and Spring provides the only comprehensive library set that can handle all those options. Learn one Spring library and the others will feel simialar, and so it's more natural to get started with a new API and technology. In the way that APIs designed with idiomatic Python APIs are said to be "Pythonic," Spring's APIs are cohesive and work nicely together. However, if Java's not your cup of tea (punny!), then that's OK too. CloudFoundry supports Ruby on Rails, Scala, Node.js, and other cloudfoundry providers support alternatives (Stacato supports Python, AppFog supports PHP, etc.)
For a quick example demonstrating how to get started with Spring, and the SpringSource Tool Suite, and a development virtual machine for CloudFoundry (so you can develop locally and quickly), check out this blog (and, particularly, the video embedded therein): http://blog.springsource.com/2011/08/24/micro-cloud-foundry-for-spring-developers/
The Springsource team has been doing some interesting work this year integrating a variety of Spring projects with Cloud Foundry.
With the rising popularity of microservices, many of the Spring projects are proving to be useful not only for quickly developing these smaller, lighter weight services, but also for easily incorporating some of the projects from Netflix OSS that implement patterns for making them industrial strength even at web scale.
A few related links:
The latest Cloud Foundry Java buildpacks include support for Spring
Boot and Spring Auto-reconfig (https://github.com/cloudfoundry/java-buildpack/releases).
The CF docs
contain an example on deploying Spring Boot apps to Cloud Foundry or
Heroku
The new Spring Cloud project will "Integrate your application with Pivotal Cloudfoundry. Makes it easy to implement SSO and OAuth2 protected resources, and also to create a Cloudfoundry service broker."
I look forward to seeing more of the results from the collaboration between the Cloud Foundry and Spring teams. One evidence of this is a recent tweet from Pivotal's James Watters "As the Microservices trends take off its pretty amazing to have the world's leading lightwieght #springframework on same team as CF."