I have been trying out kubernetes on GCP to build microservices for a while and it has been amazing so far.
Although i am a bit confused on what would probably be the best approach, should i
create (gcloud container clusters create "[cluster-name]" ...) one container-cluster per service?
create one container-cluster for multiple services? or
do both of those above depending on my situation?
all of the examples i have managed to find has only covered #2, but my hunch is kind of telling me that i should do #1, and my hunch is also kind of telling me that i have probably missed some basic understanding around containers, i have been trying to find answers without any luck, i guess i just can't figure out the right search keyword, i am hoping that i could find some answer here.
I suspect the answer is "it depends" (Option 3)
How isolated do you need each application to be? How much redundancy (tolerance of VM failure) do you need? How many developers will have access to the Kubernetes cluster? How much traffic do the apps generate?
If in doubt I recommend running all your apps on a single cluster. Simpler to manage and the overhead in providing highly available infrastructure is then shared. You'll also have greater levels of VM utilization, which perhaps might result in reduced hosting costs. The latter is a subjective observation, some apps have very little or occasional traffic resulting in very bored servers :-)
Related
Could you help me in one thing?
I have got a project with few deployments - databases, app1, app2, monitoring etc.
I have a very specific system that needs to be scaled with multiple metrics that are stored in monitoring system.
I have created a small microservice which checks if conditions are met (it's not something like simple GET - there is a whole algorithm that calculates it) and scales the environment (oc app or curl - it doesn't matter at this point).
Here's my question - is it a good solution? I wonder if it can be done in a better way.
And the second one - is it okay to create new serviceaccount with edit role just to perform scaling?
I know it's not complicated when you have some experience in openshift but this system is so specific (autoscaling managed by algorithms) that I couldn't find anything useful in docs.
Thank you.
This question is not directly on code or to debug rather more on a solution.
Working on defining a solution around the following requirements:
Consume data from diverse upstream systems.
Publish the data to the subscribers.
Straight forward to some extent because I need to identify the suitable pub/sub mechanisms which best suites for enterprise platform, but point 1 is where I am facing some complexity because I am confused about whether to go for push approach or pull approach.
For a push approach, what I can think of is to use MQ as a broker in between and define the standard message format for the upstream systems. But the main drawback with this approach is, there will be a some level code changes at the upstream systems.
So, why not the pull approach? If this question arises, then I don't have the right answers because I could not think of any way to pull the data from the source systems without the native services available with source systems. Please suggest some of the approaches best suited for this problem.
Please do not suggest on ESB kind of solutions because, this is a simple case which we are trying to solve and hence ESB will be an overkill. Please let me know if my question is not clear.
I have been going through the book "High performance mysql", its really a nice book. But the only concern for myself is the MySQL sharding part. Even though there are a lot of theories but the practical implementation is lacking and some of the aspects are also like blackbox (arranging shrds on node). It would be great if somebody can point me to some case study article or paper so that i can under it properly.
Thanks in advance!!
I found one [link] (http://tumblr.github.com/assets/2011-11-massively_sharded_mysql.pdf). please share more if somebody has. Thanks.
Yes, "sharding" is rather a design/development pattern... It's not a database feature of any kind, I would call it "it's like the database had outsourced the scale-out capability to the application".
I work for ScaleBase (http://www.scalebase.com), which is a maker of a complete scale-out solution an "automatic sharding machine" if you like, analyzes the data and SQL stream, splits the data across DB nodes, load-balances reads, and aggregates results in runtime – so you won’t have to!
No code changes, everything continues to work with “1 database”. Your application or any other client tool (mysql, mysqldump, PHPMyAdmin...) connects to ScaleBase controller (looks and feels like a MySQL), which is a proxy to a grid of "shards", automating command routing and parallelizing cross-db queries, and merge results – exactly as if the result came from 1 database. ORDER, GROUP, LIMIT, agg functions supported!
Also, please visit my blog, http://database-scalability.blogspot.com/, all about scalability...
ScaleBase my company had a webinar not so long ago, specifically about sharding and data distribution. Amazingly it's not (yet?) in the http://www.scalebase.com/resources/webinars/. I'll see if they can upload it, or I'll have the slides attached here, or similar. Stay tuned!
Hope I helped...
Doron
I'm just getting started with interfacing to MySQL from a C++ app. The app is pretty simple: it's a Linux web server, and the C++ code retrieves JavaScript from a local database to return to the client via Apache and Ajax. The database will contain no more than a few thousand short JavaScript programs.
Question: any advice on which API I should use? I'm just reading through the docs on dev.mysql.com, and there doesn't seem to be any good reason to choose one or other of libmysql, Connector/C, Connector/C++, MySQL++, or Connector/ODBC. Thanks.
With no more than a few thousand rows, chances are, you should pick your API after your language preferences, not the other way round - so go aheead and chose whatever fits your mood.
If your app's performance stands and falls with the performance differences of the MySQL connectors you should be quite busy fixing your design elsewhere.
I personally prefer portability, so I tend to use a lot of ODBC, accepting the small performance hit, but others might think different. If you never ever want to use a different RDBMS stay away from ODBC - without the portability benefit it's quite ugly.
I would just use the raw C API. Seems to be the simplest way with the least overhead.
We are developing a web application, which will have a database with over 5 millon documents, all of them will be in various languages. The site is planned to have more than 3 million visits per month (hopefully more).
We need a stable and scalable solution.
We are now using Java EE over JBoss application server with PGSQL DB, but we would like to know if this fits the problem or there is a better solution, because the project is a the beginning and changes are yet viable.
Also, as many of us, doesn't have a lot of experience with this type of projects, the opinions of the ones who does, will be very useful!
I hope I made myself clear. Please let me know if you need more information.
Thanks in advance.
The architectural design considerations of your solution are probably more important than the choice of "platform". In other words, how are you going to make your application scale? Do you need to store distributed session? Do you need real-time database synchronization or something a little less up to date? How will you do request load balancing, or handle fail over? Can the business logic work over a distributed set of nodes/sites or whatever you envisage.
Once you have a design that suits your purposes then the choice of your implementation platform can be a better informed decision. Whether it's java, .net, rails or whatever doesn't really matter. They all have their strength and weaknesses, as do the members of your team. Use their strengths to guide this part of your decision making process. Don't try to learn a new technology in tandem with building what sounds like a fairly serious site.
I've used JBoss on a pretty large distributed ebook delivery system with tens of thousands of page views per day and it never missed a beat. Likewise I think Stack Overflow is a more than adequate example of the capabilities of the ASP.NET platform with regards to the numbers you are mentioning.
Hope that helps.
I personally would not take responsibility to offer own solution to a team without asking for advice from somewhere else first. Same way as chaKa does. What I would not do is to rely on one source of help making final decision.
You may need to consider following criteria:
How much time do you have? What is development plan? Should you start right away or you will be given time to learn.
Do you need framework? Are you expected to deliver quickly? How many requirements do you have? It all affects will it be framework based solution or from scratch.
Will you support project as well? How many people will do it? You need to know also will project grow slowly or it should be deployed quickly and forgotten.
What skills does your team have? What are they good at?
What would make you excited and want to do your best implementing solution?
I believe there is more to think about...