I am new to Kubernetes.
Last few days, I did performance test for API Gateway to compare both environments, Kubernetes and Native.
I expected to get similar results in both types of tests, but the second test showed a 20% tps loss.
How to stress : RestfulAPI requests through API Gateway.
Env 1 : Native (CentOS) - result : approximately 1700 tps
Evn 2 : Kubernetes - result : approximately 1350 tps
* Hardware specifications were the same.
I wonder if this is a common result.
In my opinion, 20% is too much loss.
Sorry for my stupid question, but I am confused.
According to k8s documentation
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot.
Wikipedia also says:
Kubernetes (κυβερνήτης, Greek for "governor", "helmsman" or "captain")
Obviously, the captain’s advantages are not in speed but in the predictability of the work of the entire complex system as a whole
k8s strengths are:
Service discovery and load balancing
Storage orchestration
Automated rollouts and rollbacks
Automatic bin packing
Self-healing
Secret and configuration management
As you can see, the performance gain is not mentioned here.
P.S. There is great comment on HN discussion about Serverless hype (TL;DR: slowness and costiness):
It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other products that are often discussed on HN.
But let's be clear, we are talking about commercial products and there is a capital interest in selling these services to all of us devs and engineers.
So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel that we should be MUCH more insistent in pointing out when a product does not make sense instead of jumping onto the hype train.
I am basically surrounded by "LETS TRANSFORM EVERYTHING TO KUBERNETES THIS WEEK!" exclamations, conferences are basically "DID YOU ALREADY HEAR ABOUT KUBERNETES?" and so on ...
It reminds me of Ruby on Rails, a mature and well-developed framework used by global tech firms (correct me if wrong: Airbnb, ~Stack Overflow~, Github) to handle parts of their backend in 2019. But for half a decade now even tiny companies have been screaming around about FancyHTTPTechThisYear (tm) because scale while reporting 1/500th of the traffic of some famous Rails users.
This is not engineering with objectives in mind, it's more akin to the gaming community yelling for a new console.
Related
On Db2 v11.1, how do we get or setup the notification for DBA team if there is any hang or slowness situation in off shift working hours?
The answer depends on the external monitoring and alerting solution you deployed, and how you configure that tooling in your environment.
This application layer tooling is not built into Db2-LUW, although APIs exist in Db2-LUW for such tooling to get the data it needs in order to operate.
IBM and several third parties offer solutions for real time monitoring and alerting in this space. Many cover app-servers, web-servers, database layers, networks and operating-system layers and have different alerting configurability. Many have plugin type architecture with plugins for Db2-LUW monitoring. Do not use stackoverflow for product recommendations however.
For "slowness", this is only meaningful to measure usually at the application layer, in terms of response times and other metrics etc.
For database-hangs, IBM offers a db2-hang_detect script that tooling can orchestrate , requires careful interpretation and even more careful testing.
I’m proposing a project to my school supervisor, which is to improve our current server to be more fault tolerant, easily scaling and able to handle high traffic.
I have a plan to build a distributed system starting from deploying our server to different PCs and implement caching and load balancing, etc.
But I want to know whether Kubernetes already can satisfy my objective？ what are the tradeoff between using Kubernetes and building own distributed system to deploy applications？
Our applications are built with Django and most are likely used by students such course planner or search/recommend systems.
You didn't give any details of your app, so I'll provide some generic thoughts. Shortly speaking, Kubernetes gives you scheduling, load balancing and (sort of) high availability for free. You still have to plan proper application architecture but Kubernetes gives you a good starting point where you can say like "ok, I want this number of app containers to run on this number of nodes". It also gives you internal load balancing and DNS resolution.
Of course, the tradeoff is that you have to learn Kubernetes and Docker up to some certain point. But I wouldn't say it's too hard for enthusiast.
I’m proposing a project to my school supervisor, which is to improve our current server to be more fault tolerant, easily scaling and able to handle high traffic.
This is a great idea. What you really want to do here is to use as many existing tools as you can, to let you focus on improving the core functionality of your current server - e.g. serving your users with your business logic and data and increase availability of this.
Focusing on your core functionality means that you should NOT do, e.g.
NOT write your own memory allocation algorithm or garbage collection
NOT write you own operating system
NOT write your own container scheduler (e.g. what Kubernetes can do for you)
I have a plan to build a distributed system starting from deploying our server to different PCs and implement caching and load balancing
Most applications deployed on Kubernetes or that have your availability requirements actually should be a distributed system - e.g. be composed of more than one instance, designed for elasticity and resiliency.
what are the tradeoff between using Kubernetes and building own distributed system to deploy applications?
Kubernetes is a tool, almost an distributed operating system that e.g. schedules containerized apps to a server farm. It is a tool that can help you a lot when developing and designing your distribued application that should follow the Twelve Factor principles.
We have built an enterprise web application on asp.net platform which is well load balanced across several servers. We are struggling a bit in terms of doing regular deployments as the application has been defined with an SLA of zero downtime.
Any guidance / tips would be highly appreciated for Implementing best practices to support uninterrupted deployment.
My two favorite books that cover some of these topics are Continuous Delivery by Humble/Farley and Web Operations by Allspaw/Robbins.
I think the "easy" part here is to do a rolling deployment where you pull a node out of the load balancer, upgrade it, run smoke tests, and place it back in the load balancer. Different users will encounter different versions of the app, but you get zero downtime.
The hard part is the backend system / database that these web-apps are likely hitting. You basically need to have both old and new schemas available concurrently which is challenging. Look at techniques like the expand / contract database pattern as an approach to pulling this off.
I'm a CS student, just exploring the SCM space. While doing my own research I came across many different hosted solutions (GitHub obviously, Lighthouse, YouTrack, TeamCity, etc.) - do you think it is actually reasonable to try to host a (commercial, closed source) project entirely in the cloud?
Let's say I'd host code on GitHub, use Jira or Lighthouse for issue tracking, God knows what other hosted PM solution (Basecamp?) and build using EC2 (I can put Hudson or TeamCity on it and use appropriate EC2 plugins for these products to get more computing power when needed).
Is the EC2 bill going to kill me (compared to self-hosted solutions)? Do you think "the cloud" it's still not reliable enough?
This is the way we work at our company. Version control system (git) + agile planning + ticket system/bugtracker + wiki are hosted at http://www.assembla.com for 49$/month for 40 users, private repositories ( https://www.assembla.com/plans ) and we have a micro instance on amazon aws ec2 where jenkins, nexus, sonar and some internals tools are running for free the first year and then you should consider spending like 80$/month for the same service.
So it costs 129$/month for a full cloud solution for a small company (40 users max): reliable, with a good release train of new features by our service providers and with a low maintenance footprint for us.
Compared to self hosted it's not really expensive considering the following costs :
- price of your server (lets say 1000$)
- electricity bills (lets say 30$/month for 100% uptime)
- cost of configuration (to get the same quality as assembla for exemple) and maintenance (lets say 0.5day man per month at 500$/day in france)
The cost is : 363$/month
This should look a bit biased, but finally it's what we experienced.
Regards,
Xavier
There is no problem to use the cloud for hosting, and many large companies do so already. I think NetFlix recently moved solely to EC2. Our whole business runs on EC2, and it's been relatively good so far.
The EC2 bill is up to you to manage -- cloud is all about granular billing for services, and the more you consume the more you pay (we sell a tool that helps with cost controls: http://LabSlice.com). Your biggest cost will usually be CPU power, so stick to the Micro/Small instances until you've got a handle on costs.
It's interesting that people question the reliability of cloud, as the underlying premise is actually to provide more reliability to businesses then they could afford themselves (high scalability, immediate availability of hardware, monitoring, load balancing etc.)
You can make use of AWS Free Account and host your application. If you exceed Free Account Usage limit,you will be charged for whatever extra you have utilized.
Regarding reliability about Cloud, every big firm is moving towards Cloud like Amazon,Microsoft,IBM,HP etc because they found cloud reliable,cost effective and green.
Given your a student and assuming your looking to spend little money, a lot of Git and SVN hosting providers offer free hosting for students or free accounts if your a small team with minimal storage requirements. Check out Codesion's student offering for example (disclaimer, I work for Codesion). This plan also comes with Trac / Bugzilla for your PM requirements. I wouldn't be concerned with security and reliability for the same reason that Simon points out above.
As for CI on EC2 - this is probably your best bet since you pay by the hour each instance is running. I'd recommend using Amazons API to fire up an instance each time Hudson needs to perform a build, store the results of the build on more permanent storage, and shut the instance down when finished. If your doing a lot of CI builds, it might be better to just keep the instance running, but this will cost you more of course.
It seems that SaaS and Cloud computing are old concepts with new names, and I am curious if I am wrong.
For cloud computing you can look at: Difference between cloud computing and distributed computing?
Basically, it seems that when we have been hosting that that is cloud computing, it is just that now some companies have put in much great resources to ensure better uptime than my local ISP. But, it seems that there is nothing really new here.
For REST, it seems that it is what we have been doing with cgis for 15 years.
Here is a question on REST: What am I not understanding about REST?
It appears that REST is an old concept, and I am curious how it is different than has been done since the early days of the web, and, to a large extent, the early days of using telnet (which http is on top of).
Am I mistaken in my simplification of these? I try to see how what is new is like what I know so I can see what more has to be learned in that topic, but for cloud computing and REST it seems that very little needs to be learned.
You are both right and wrong. You are right in the sense that new ideas are normally similar to old ideas, and indeed cloud computing is based significantly on distributed computing.
What is new in cloud computing is
virtualization
self-service
With virtualization, you can run multiple operating systems on a single hardware. While that, in itself, isn't new, either, it was never considered in distributed systems as a relevant piece of the architecture. Using virtualization allows self-service: users can create their own clusters of nodes without the administrator of the hardware taking any action. This allows a significant acceleration of deployment, and a significant reduction of cost.
For ReST, what you are missing is the client API. It is true that on the server side, a ReST service can be implemented with CGI. What is new here is that it is not an end user which retrieves the URL, but a program.
Saying that HTTP is on top of telnet ignores realities; this is like saying that we made no progress since the introduction of copper wires for communication. Strictly speaking, HTTP is not in top of telnet, but on top of TCP (which telnet is also on top of, these days).
Considering Roy's dissertation coined the term REST back in 2000, you can definitely argue that there is nothing new about REST. Additionally, the REST architectural style was synthesized from successful existing practices, so REST implementations pre-date the definition. Having said that, there is nothing simple about designing REST interfaces. Ever since Netscape first abused cookies to allow servers to maintain session state people have been swimming upstream against the web.
REST's recent resurrection has come mainly from people becoming disillusioned with SOAP based Web Services. SOAP tried to hide HTTP instead of embracing it and I think people are starting to realize how effective HTTP can be as an distributed application protocol that can do more than just deliver HTML to web browsers.
RESTful web applications don't use session state, so one could argue that by that virtue alone it is different than most web applications in existence at the moment.
As for Cloud Computing, I find myself agreeing with Larry Ellison for once in my life.
I'm in agreement on what you've posted. You might consider making this community wiki since it's likely to garner many answers based on opinion. Cloud computing seems to have taken off as a buzzword, and this is largely due to a decrease in cost for mass quantities of hardware. And then there is REST which is really just a formal name and definition for something that has been in place for a long time. Some people like to encapsulate ideas with buzzwords and acronyms. Sometimes it's useful to put a name to an idea though.
Not only this, the concept of things being old concepts with new names is old. It's hard to be original these days :P
You are right about REST -- its mostly old concepts with a lot of added pedantry and not much added substance.
Cloud computing has a small but fundamental difference from distributed computing. In distributed computing you had servers dedicated to particular functions, and usually some sort of directory service to locate the correct server. In cloud computing any server is capable of any task and usually the servers queue up for work which is distributed from a central point.