• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

Is it a disadvantage of microservices that multiple services will contribute to more deployment cost

 
Ranch Hand
Posts: 2601
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Multiple microservices will gives advantages but may cause more deployment cost. Is it a disadvantage of microservices that multiple services will contribute to more deployment cost?
Thanks
 
Saloon Keeper
Posts: 7353
170
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

may cause more deployment cost


Why do you think so? What is the difference between deploying 10 microservices and 100 microservices as far as deployment is concerned?
 
Monica Shiralkar
Ranch Hand
Posts: 2601
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Say that is on cloud.Now if multiple services are thus multiple deployment units which would have more cost on cloud.
 
Tim Moores
Saloon Keeper
Posts: 7353
170
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What cloud services is that? Billing for cloud services is usually by CPU time, not for what you're doing in that time - and deployments would be very quick, so not much time to pay for.

multiple services are thus multiple deployment


A microservice is generally too small to constitute its own deployment package. You would not have 100 deployments for 100 services.
 
Monica Shiralkar
Ranch Hand
Posts: 2601
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Moores wrote:What cloud services is that? .



Azure/AWS
 
Monica Shiralkar
Ranch Hand
Posts: 2601
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Moores wrote:
A microservice is generally too small to constitute its own deployment package. You would not have 100 deployments for 100 services.



I thought say if these are to be deployed in Azure cloud then one would deploy each to an App service.Not sure ,how deploying all services to 1 deployment is to be done.I will check if such option is there.Thanks
 
Saloon Keeper
Posts: 25625
183
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Moores wrote:
A microservice is generally too small to constitute its own deployment package. You would not have 100 deployments for 100 services.



Huh? If I'm going to run an elastic cloud, I definitely am NOT going to deploy manually, I'll have a canned deployment mechanism. What that mechanism is would depend on how I manage my cloud, but even with my small-scale R&D farm here I package all my deployments. It makes the process less tedious, less error-prone, and serves as a good business recovery mechanism in cases of systems failures.
 
Tim Moores
Saloon Keeper
Posts: 7353
170
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:


I don't see how any of that contradicts any of what I said...?
 
Tim Holloway
Saloon Keeper
Posts: 25625
183
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK. Let me guess what you mean, then.

I very definitely have deployment packages for my services. RPMs, containers, Ansible Playbooks, Puppet manifests and modules, or whatever. I can only assume that you meant that you wouldn't have a unique deployment package for each of 100 identical services. That is to say, 100 custom install packages, Ansible playbooks, or whatever.

No, I don't create unique packages for identical services, but since each service will have a unique home, there's usually going to be some sort of resource for targeting and configuration. Whether you want to call that part of the "deployment package" or not is a matter of interpretation, I suppose.
 
Tim Moores
Saloon Keeper
Posts: 7353
170
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I meant is that for 100 services one would not normally have 100 different units of deployment, automated or not. Maybe 5, maybe 20, but likely not 100. They would be bundled together.
 
Tim Holloway
Saloon Keeper
Posts: 25625
183
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Depends on what you call a "unit of deployment". I use a single WAR on desktop, beta, and production machines, but the actual "unit of deployment" for Tomcat consists of the WAR, a Tomcat Deployment Descriptor, and some sort of installing mechanism that knows what machine(s) to deploy copies of that WAR to.

An orchestrator such as Kubernetes may select hosts somewhat randomly, but it still has to track which hosts it runs what services in.

More generally speaking, it usually breaks down into only one deployable module, but a separate deployment profile for each target, so for 100 targets, 100 profiles built either statically or dynamically, So you can call it 1 deployment unit or 100 deployment units, depending on where the line is drawn.
 
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic