6 ms·

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in you

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down, you need alerts as well. What if there is a memory problem (because code is not optimal)? - how do you deploy the service? Plain ansible or perhaps k8s? Just scp? Depending on your solution, how do you implement rollbacks? - what about security regarding outdated packages the Go app is using? You need to monitor it as well. And so on. The moment you need to store data that somehow needs to be in sycn with the monolith's data, everything gets more complicated. Production stuff is not just about lines of code.

jhoelzel 5y ago
no why? The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs. Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhere anyway no? Deployment: Depending on anything you listed how do i do anything? Of course if have to define it but if you want a fancy example: k8s argocd canary deployments done. I literally set it up once. security? Really? Please dont get this wrong but this feels to me like whataboutism but well here i go: i implement security just the same way as i would in the monorepo. The thing/person/entity just has to look into more repositories ;) It comes down do one sentence i think: State is not shared, state is communicated.
- comradesmith 5y ago
  For monitoring I’d also say the alerting side of things can be done via the older monolith. That is, catch exceptions and log/re-raise them as “PdfServiceException”.
- rich_sasha 5y ago
  A microservice runs as some (somewhat) privileged user, you may want some auth. Can everyone internally create sales tickets? Or can everyone just query them? If a team provides a library to run, and you run it, you still only run as whatever user you have access to. Monitoring: it's easier to look at a stack trace, including some other team's external library, than a HTTP error code 500. Deployment is certainly easier when you're just shipping code and a build. You don't have to faff around with the previous instance running, maybe having some active connections/transactions/whatever, needing to launch a new one. Maybe it's not hard overall, but less fun.
  - matwood 5y ago
    > A microservice runs as some (somewhat) privileged user, you may want some auth. Auth can be a very broad term in the case of services, especially in the cloud. IAM could only allow access from certain other machines, etc...
vbezhenar 5y ago
Kek. Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number. Monitoring? Well, we have our clients for that. They'll call us if something happens. Deploy? Copy .war file and restart tomcat. Rollback? What's rollback? Outdated packages? We call those stable packages. I wish I would work in a miracle world you describe.
- stepbeek 5y ago
  This sounds dreadful. I don’t think microservices are with talking about with these basics figured out.
- paul_f 5y ago
  I cannot tell if this is satire or not. Entering Poe's Law territory
  - LaGrange 5y ago
    The answer is "both." This is very funny, very dumb, and how it's done, at the same time.
- KronisLV 5y ago
  It's easy to be snarky and dismissive about these things, but i've stood in the offices of a governmental org and have looked at people who are unable to receive their healthcare services queueing up because some similarly neglected system refused to work. One that also had a lot of the basics left out. Figuring out what was wrong with it was hard, because the logging was inconsistent, all over the place in where it logged and also insufficient. The deployments and environments were inconsistent, the sysadmins on clients's side manually changed stuff in the .war archives, all the way up to library versions, which was horrendous from a reproducibility perspective. The project was also severely out of date, not only package wise, but also because the new versions that had been developed actually weren't in prod. After ripping out the system's guts and replacing it with something that worked, i became way more careful when running into amateur hour projects like that and about managing the risks and eventual breakdown of them. I suggest that you do the same. Don't put yourself at risk, especially if some sort of a liability about the state of the system could land on you. What are you going to do when the system gets breached and a whole bunch of personal data gets leaked?
zaptheimpaler 5y ago
lol this is how it works at a startup - 1. auth? probably an internal service, so don't expose it to the outside network. 2. monitoring? if the service is being used anywhere at all, the client will throw some sort of exception if its unreachable. memory problem? it should take <1 day to ensure the code for such a small service does not leak memory. if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts will expose it. then ssh in, run `top` voila now you know which service is responsible. 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. rollback? ok, checkout previous version on git, recompile, redeploy. maybe the whole process is wrapped in a bash script or assisted by a CI/CD build job. 4. security? well ok, PDFs can be vulnerable to parser attacks. so lock down the permissions and network rules on the service. Overall this setup would work perfectly fine in a small/medium company and take 5-10x less time than doing everything the FAANG way. i don't think we should jump to calling these best practices without understanding the context in which the service lives.
- 3pt14159 5y ago
  > 4. security? well ok, PDFs can be vulnerable to parser attacks. so lock down the permissions and network rules on the service. Haha. You're a bit of an optimist, eh?
- xmaayy 5y ago
  This is scarily accurate to some of our services. Hasn't failed us yet, but we're preemptively moving to CICD with docker
- YetAnotherNick 5y ago
  I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error. > if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer and daily monitoring of each service by doing top is not feasible. > 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. Your solution literally is more complex than simple jenkins or ansible script for build then kubectl rollout restart yet is lot more fragile. Anyways the point stands that you need to have a way for deployment
tetha 5y ago
Yup. This is why I think that microservices require a stronger operational plattform, but then it enables new and more effective ways of developing new tunctionality. Our internal software plattform is getting to a point so it can answer most of these things - auth via the central OIDC providers, basic monitoring via annotations of the job's services, deployments via the orchestration and some infrastructure around it, including optional checks and automated rollbacks and automated vulnerability scanning on build-servers and for the running systems. It wouldn't be 15 lines of go, more like 15 lines, plus about 100-200 lines of terraform and/or yaml to get everything configured, and a ticket do register the service in the platform. It's pretty nice and our solution consultants like it very much. The thing is - this took a team about a year to build and it'll take another half a year to get everything we currently want to do right. And it takes a non-trivial time to maintain and support all of this. This kind of infrastructure only makes business sense, because we have enough developers and consultants moving a lot faster with this. Back when we were a lot smaller, it made a lot more sense to just push a single java monolith on VMs with chef or ansible, because that was a lot easier and quicker to get working correctly (for one thing).
koffiezet 5y ago
Many of these points you're mentioning is exactly why k8s was developed. Yes it makes deploying simple applications unnecessary hard, but it make deploying more complicated applications WAY more manageable. So in the k8s world: - auth: service meshes, network policies, ... - monitoring: tons of tooling there to streamline that - deploy: this at scale is trickier than you'd think, many seem to assume k8s on it's own here is the magic dust they need. But GitOps with ArgoCD + helm has worked pretty well at scale in my experience. - Security is a CI problem, and you have that with every single language, not just Go. See Log4j. Kubernetes is my bread & butter, but I do realise this has way too much overhead for small applications. However, once you reach a certain scale, it solves many of the really really hard problems by streamlining how you look at applications from an infrastructure and deployment side of things. But yes - you need dedicated people who understand k8s and know what the hell they're doing - and that's in my experience a challenge on it's own. Let's also dispel a myth that k8s is only suitable for microservices. I have clients that are running completely separate monolith applications on k8s, but enough of those that managing them 'the old way' became very challenging, and moving these to k8s in the end simplified thing. But getting there was a very painful process.
- p_l 5y ago
  My first production k8s deployment involved around 60~70 monoliths packed tightly onto small amount of hardware. Saved a lot of money :) (And yes, if you need extra argument to sell k8s, remind them about bin-packing more applications onto less hw)
Kiro 5y ago
You don't need any of that stuff.
p_l 5y ago
Well, it quickly can become a mess because of people having different ideas about what microservice is, and also decrying things as "for microservices only" when for example I just want to offload auth and monitoring to a specialized service. It's also a common trope when I'm dealing with k8s decriers - yes, you might have one application that you can easily deploy, but suddenly there are 15 other medium-weight applications that solve different important problems and you want them all ;) P.S. Recently a common thing in my own architectures is separate keycloak deployment that all services either know how to use, or have it handled at separate request router (service mesh or ingress or loadbalancer)

jhoelzel 5y ago

no why? The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs. Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhere anyway no? Deployment: Depending on anything you listed how do i do anything? Of course if have to define it but if you want a fancy example: k8s argocd canary deployments done. I literally set it up once. security? Really? Please dont get this wrong but this feels to me like whataboutism but well here i go: i implement security just the same way as i would in the monorepo. The thing/person/entity just has to look into more repositories ;) It comes down do one sentence i think: State is not shared, state is communicated.

comradesmith 5y ago
For monitoring I’d also say the alerting side of things can be done via the older monolith. That is, catch exceptions and log/re-raise them as “PdfServiceException”.
rich_sasha 5y ago
A microservice runs as some (somewhat) privileged user, you may want some auth. Can everyone internally create sales tickets? Or can everyone just query them? If a team provides a library to run, and you run it, you still only run as whatever user you have access to. Monitoring: it's easier to look at a stack trace, including some other team's external library, than a HTTP error code 500. Deployment is certainly easier when you're just shipping code and a build. You don't have to faff around with the previous instance running, maybe having some active connections/transactions/whatever, needing to launch a new one. Maybe it's not hard overall, but less fun.
- matwood 5y ago
  > A microservice runs as some (somewhat) privileged user, you may want some auth. Auth can be a very broad term in the case of services, especially in the cloud. IAM could only allow access from certain other machines, etc...

vbezhenar 5y ago

Kek. Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number. Monitoring? Well, we have our clients for that. They'll call us if something happens. Deploy? Copy .war file and restart tomcat. Rollback? What's rollback? Outdated packages? We call those stable packages. I wish I would work in a miracle world you describe.

stepbeek 5y ago
This sounds dreadful. I don’t think microservices are with talking about with these basics figured out.
paul_f 5y ago
I cannot tell if this is satire or not. Entering Poe's Law territory
- LaGrange 5y ago
  The answer is "both." This is very funny, very dumb, and how it's done, at the same time.
KronisLV 5y ago
It's easy to be snarky and dismissive about these things, but i've stood in the offices of a governmental org and have looked at people who are unable to receive their healthcare services queueing up because some similarly neglected system refused to work. One that also had a lot of the basics left out. Figuring out what was wrong with it was hard, because the logging was inconsistent, all over the place in where it logged and also insufficient. The deployments and environments were inconsistent, the sysadmins on clients's side manually changed stuff in the .war archives, all the way up to library versions, which was horrendous from a reproducibility perspective. The project was also severely out of date, not only package wise, but also because the new versions that had been developed actually weren't in prod. After ripping out the system's guts and replacing it with something that worked, i became way more careful when running into amateur hour projects like that and about managing the risks and eventual breakdown of them. I suggest that you do the same. Don't put yourself at risk, especially if some sort of a liability about the state of the system could land on you. What are you going to do when the system gets breached and a whole bunch of personal data gets leaked?

zaptheimpaler 5y ago

lol this is how it works at a startup - 1. auth? probably an internal service, so don't expose it to the outside network. 2. monitoring? if the service is being used anywhere at all, the client will throw some sort of exception if its unreachable. memory problem? it should take <1 day to ensure the code for such a small service does not leak memory. if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts will expose it. then ssh in, run `top` voila now you know which service is responsible. 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. rollback? ok, checkout previous version on git, recompile, redeploy. maybe the whole process is wrapped in a bash script or assisted by a CI/CD build job. 4. security? well ok, PDFs can be vulnerable to parser attacks. so lock down the permissions and network rules on the service. Overall this setup would work perfectly fine in a small/medium company and take 5-10x less time than doing everything the FAANG way. i don't think we should jump to calling these best practices without understanding the context in which the service lives.

3pt14159 5y ago
> 4. security? well ok, PDFs can be vulnerable to parser attacks. so lock down the permissions and network rules on the service. Haha. You're a bit of an optimist, eh?
xmaayy 5y ago
This is scarily accurate to some of our services. Hasn't failed us yet, but we're preemptively moving to CICD with docker
YetAnotherNick 5y ago
I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error. > if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer and daily monitoring of each service by doing top is not feasible. > 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. Your solution literally is more complex than simple jenkins or ansible script for build then kubectl rollout restart yet is lot more fragile. Anyways the point stands that you need to have a way for deployment

tetha 5y ago

Yup. This is why I think that microservices require a stronger operational plattform, but then it enables new and more effective ways of developing new tunctionality. Our internal software plattform is getting to a point so it can answer most of these things - auth via the central OIDC providers, basic monitoring via annotations of the job's services, deployments via the orchestration and some infrastructure around it, including optional checks and automated rollbacks and automated vulnerability scanning on build-servers and for the running systems. It wouldn't be 15 lines of go, more like 15 lines, plus about 100-200 lines of terraform and/or yaml to get everything configured, and a ticket do register the service in the platform. It's pretty nice and our solution consultants like it very much. The thing is - this took a team about a year to build and it'll take another half a year to get everything we currently want to do right. And it takes a non-trivial time to maintain and support all of this. This kind of infrastructure only makes business sense, because we have enough developers and consultants moving a lot faster with this. Back when we were a lot smaller, it made a lot more sense to just push a single java monolith on VMs with chef or ansible, because that was a lot easier and quicker to get working correctly (for one thing).

koffiezet 5y ago

Many of these points you're mentioning is exactly why k8s was developed. Yes it makes deploying simple applications unnecessary hard, but it make deploying more complicated applications WAY more manageable. So in the k8s world: - auth: service meshes, network policies, ... - monitoring: tons of tooling there to streamline that - deploy: this at scale is trickier than you'd think, many seem to assume k8s on it's own here is the magic dust they need. But GitOps with ArgoCD + helm has worked pretty well at scale in my experience. - Security is a CI problem, and you have that with every single language, not just Go. See Log4j. Kubernetes is my bread & butter, but I do realise this has way too much overhead for small applications. However, once you reach a certain scale, it solves many of the really really hard problems by streamlining how you look at applications from an infrastructure and deployment side of things. But yes - you need dedicated people who understand k8s and know what the hell they're doing - and that's in my experience a challenge on it's own. Let's also dispel a myth that k8s is only suitable for microservices. I have clients that are running completely separate monolith applications on k8s, but enough of those that managing them 'the old way' became very challenging, and moving these to k8s in the end simplified thing. But getting there was a very painful process.

p_l 5y ago
My first production k8s deployment involved around 60~70 monoliths packed tightly onto small amount of hardware. Saved a lot of money :) (And yes, if you need extra argument to sell k8s, remind them about bin-packing more applications onto less hw)

Kiro 5y ago

You don't need any of that stuff.

p_l 5y ago

Well, it quickly can become a mess because of people having different ideas about what microservice is, and also decrying things as "for microservices only" when for example I just want to offload auth and monitoring to a specialized service. It's also a common trope when I'm dealing with k8s decriers - yes, you might have one application that you can easily deploy, but suddenly there are 15 other medium-weight applications that solve different important problems and you want them all ;) P.S. Recently a common thing in my own architectures is separate keycloak deployment that all services either know how to use, or have it handled at separate request router (service mesh or ingress or loadbalancer)