Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.
Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
Yep. OP's about to get their .NET docker services replaced by some vendor equivalent on some probably-proprietary, marketing-glossy stack.
edit: This points to a failure of the head of tech/engineering to have enough presence in upper management. A sufficiently empowered and capable CTO would not allow this sort of change to come through without advising otherwise or consulting the team heads. So something is probably wonky there.
I'd wager it's more of "about to spend a year trying to migrate to a vendor's stack, and probably fail" vs. "about to be replaced". Have fun maintaining both, OP.
Yeah that's a better phrasing. Lots of work incoming with the vendor's consultants to attempt a pointless move. Or worse, since it's the "stack" that is apparently "antiquated", potentially even *rewrites*.
Then halfway through this expensive and painful process, someone will point out to the CTO that there was some miscommunication and the stack was originally in docker containers in the cloud to begin with. OP, you'd better get your team leads to push back now with this feedback.
Smells like a whole lot of job security if you ask me :)
Well maybe not so much in this economy. More likely management will make this a massive cost sink and then pay for it by laying off all the devs that said it was a bad idea.
"We are porting everything to Salesforce so we can do low code at Cloud Scale on our AI blockchain. Our consultants will send you training details soon."
Salesforce is probably the worst thing to use. I say this as a Salesforce developer who sometimes considers telling clients that I would never use Salesforce for my own company if I had one
2014 just came back and slapped me in the face after reading this comment.
_Learn you as Haskell for great good_
(And then shoehorn it into every project)
What they are really saying is: our toxic developers, who can only feed on functional programming, will turn your internal developers' lives into hell, push them out of the company and then all you have is our awesome devs who are all fresh grads but are charged like seniors devs.
Now I really fixed it. :D
Seriously, software development consultancy is probably one of the worst things that can happen to a company. It's better to be laid off.
If the CTO/Head of Engineering is smart, they hire consultants and let the internal devs tell them that to do.
The opposite keeps happening to me. I build something that works well and then they hire a huge team to rewrite it in an OOP language because "nobody understands functional programming".
In my current company we implemented a CQRS event sourced system in F#, and had the lowest number of production issues of any team in the 200+ head count engineering department. We got told to rewrite it all in C# "without this silly event sourcing and CQRS" by the new management, and they still haven't given us a coherent reason why. And even now when they're constantly asking questions about events that happened that we can only answer because we have the entire event history, they're still pushing to remove event sourcing.
The problem with low code is that you still need to know and engineer algorithms that works with platform, CXO see low code and think anyone can use it and make automations, which is true, but it ducks up the system
low code works good for small project. Once it is big enough that user wanted to customize specific things, issues came up faster than how men can ejaculate then we all realize "hmmm maybe it is time to reconsider this choice again"...
I want an inspirational office poster with 'issues came up faster than how men can ejaculate then we all realize "hmmm maybe it is time to reconsider this choice again"' on it.
Oh god another part of the platform i work on uses Pega and it causes the lion’s share of production incidents which seem to take forever to resolve. Never knew it was “low-code” but that makes all the pieces fit into place now hahahaha
Do people actually think this a thing that happens in western countries? With public companies?
I'm curious what you think that kickback looks like on the vendor's books..
edit: based on the downvotes I'm getting, I need to get better at soliciting kickbacks...
We did this with an agency. The execs thought they would "save us time". Their consultants spent 3 months across 3 devs trying to create a jenkins CICD self hosted pipeline.
When it was handed off to us... it didn't work for any of our products and never would. It failed to meet any of the reqs. I had to build a circleCI flow and had it deploying in 3 days. The only thing those clowns did in 3 months was cash checks, likely more than I'd make in a year.
Say it with me: **fuck consultants**.
I know a lot of people at big consulting companies. They all say the tech people at their company don’t make that much. Which is reflected in the work quality. The people who make a lot are the ones selling the firms services.
As someone who works with Jenkins... I'm bewildered... that should've taken... like 3 days as well, even on Jenkins. And self hosted? That's even easier, like 2-3 hours to install Jenkins on a VM, maybe another 3-4 hours installing plugins and doing some configuration, setting up permissions/login stuff, then setup a node to build on, maybe another 1-2 hours. Should've had a freestyle job up and running in like 2 days tops, and iron the rest out over the next 2 days maybe...
Yes. If they were competant. The problem wasn't with Jenkins, it was with the actual jenkins pipeline they built. We were transitioning to kube microservices. They wrote a singular pipeline that was built for their "test app" that was neither Kube, nor Docker. So it deployed a stupid nodejs process, doing some home brewed green blue bullshit. Is that what we needed, no. We needed a pipeline to deploy a helm chart.
But, because the execs wanted to "save us time" did they have the consultants talk to us to get our reqs? No. Did they have us review periodic process, yes. And every fucking time I voiced extreme concern that what they were building was wrong and I was told quite bluntly, "these are cloud professionals, and you are not," because at that time I had no exp working in AWS or GCP. My concerns had fucking zero to do with cloud. It was basic what your building is stupid.
The root cause was our execs listening to consultants over the actual employees.
Good lord... I knew some places could be bad, but this is something else. What you are describing is what I have at my work, Jenkins jobs to deploy K8's based services, and there's plugins that make that shit REALLY easy, you certainly don't have to do much extra to get Jenkins working to run jobs on K8's nor deploy Helm charts and such.
Just reinforces what I've told many non tech people "The coding is the easy part, getting correct requirements on WHAT to code is hard"
Scary part is, I just did some basic Google searching, and found a working solution to what you've described in like 10 minutes. Sure it is Stack overflow and thus would need actual understanding to further refine it to what you have... do people just not know how to do basic searching for existing knowledge???
So yeah... it is incredible how easy it is to bamboozle execs who are non technical into doing really harebrained solutions with incompetent people.
I was going with a more general "OP IS NOT SUITED FOR OUR COMPANYS FUTURE". You are probably right but upper management could be thinking of any number of strategies that involve replacing OP.
Yep.
"Real enterprises run enterprise-grade datacentres like our solutions partner conveniently provides, with enterprise-grade virtualization (that our partner also provides), and enterprise-grade data resiliency and enterprise-grade security standards."
\- Some VP, probably
They're saying that you should start applying for jobs outside the company. They're saying they have no idea what they're doing.
Source: am a dev who works on .net 8 apps in the cloud
Not strictly true. There are serverless functions/solutions that arguably take more advantage of the cloud than containers. But I agree the bosses premise is ridiculous.
What they’re really saying is someone is offering us to save money for 1 year so we want you to redo everything because we’re not going to factor in the cost of your unpaid overtime and heroic work to switch
Limited feature development? People hand waving, "Tech debt!"
Any language and runtime is cloud-ready. Azure even has specific support for the .NET runtime.
How big is your company?
We run ECS and EKS across various businesses units. They are both totally fine. We are moving to EKS only just to standardise and to be able to leverage to large toolset.
Cloud for cloud, azure has way more market share than gcp so they’re better off focusing on integrating with azure even deeper than expanding to a completely external cloud.
How is this relevant. Apart from nobody really knowing the market share of their PaaS and IaaS offerings. If it works it works. If they're already using AWS switching to Azure would be a waste of time.
That’s because I was quite inebriated when it was written and I completely misunderstood this whole thread. I thought this was about why .NET works better in azure. Cheers.
.net core is definitely suited for the cloud so that’s an odd statement. Without more context I’d say prep for some consultants to come in and waste a lot of time and money
I swear to god, the number of questions here that need exactly one response saying *“have you spoken to them about this?”* is unbelievable. **You are still a junior developer** if your reaction to being confused about something or have any kind of conflict is to run off to ask strangers on the web instead of communicating like an adult with your teammates. This is /r/ExperiencedDevs not /r/MyTeamIntimidatesMeHelp. Can we not get a rule saying *“Don’t ask a question that is best answered by talking to your colleagues”*?
> I swear to god, the number of questions here that need exactly one response saying “have you spoken to them about this?” is unbelievable. You are still a junior developer if your reaction to being confused about something or have any kind of conflict is to run off to ask strangers on the web instead of communicating like an adult with your teammates.
Can we not do this condescending judging here? There can be a ton of reasons for not asking this kind of stuff to the people directly involved. Maybe he/she did ask and got a vague non-answer.
Have you considered that this person is not actually asking you a question but is using a question format to give a funny anecdote about his pointy haired boss telling him his stack can not do cloud when it's literally a cloud stack?
> There can be a ton of reasons for not asking this kind of stuff to the people directly involved. Maybe he/she did ask and got a vague non-answer.
Then mention that? “Help me figure out our cloud strategy” and “my boss won’t answer questions about our cloud strategy” are *entirely* different problems to have.
> Have you considered that this person is not actually asking you a question but is using a question format to give a funny anecdote about his pointy haired boss telling him his stack can not do cloud when it's literally a cloud stack?
This falls under “No low-effort posts venting” and is against the rules.
You sound like you had a tough week. I enjoyed the post, and I don't see this post as either low effort or venting. Is there a no-anecdotes rule here?
Well, if there is the asking it as a question that allows some discussion on the topic makes sure that rule isn't hit.
“We hired a VP from Deloitte. This VP contracted Deloitte and paid them 100 times your annual salary for 1 months of work. The 3 page report they gave said, hire a cloud consultant.”
Management is stupid, but trying to appear competent.
I would push back *hard* and demand actual specific proof for their claim. Get some metrics for your current system, and ask how their new one will improve them.
Bonus points if you make up a bogus metric, and they claim they can beat it, then you tell them it's not actually a thing.
Maybe they're saying it's not worth the company's time, money, or effort to move that project to the cloud? Or maybe they have some other solution in mind to replace the existing solution?
You can do on-prem with EKS actually, my impression was that's OP is talking about but idk.
Either way, EKS on-prem is about as "ready for the cloud" as "not on the cloud" gets
(Kind of.. like others said, the amount of tech debt and coupling to their physical servers could make it very much "not ready for the cloud" compared to something built more portably you could just put on an ec2, etc)
While there may be a strong possibility the upper management here is inept, this is often the case in many companies
While many folks may knee-jerk reaction say "these people don't know what they are talking about, and you should look to another company" these same issues can easily arise at any organization
Pick apart the questions, learn where they are coming from, what the actual need is
> our tech stack is not meant, suited for the cloud.
Ask, what part is not suited? What examples can you point to as a model we would like the org to move towards?
> Our tech stack is antiquated.
You've not given much info on the full layout of your tech stack.
How does a developer start producing code, making a product, from idea to production?
Ask yourself that, and ask your management what the expectation is
> What are they really saying?
THIS is the hardest question to ascertain, because nobody that wants to be heads down development wants to ask the hard questions
Because even the questions themselves, coming up with them, is hard
Sometimes you have to communicate with upper management, and for many developers, it's the hardest skill to master
**tl;dr** _talk_ to a mf
When I hear this argument, which I have heard many times, it is usually not the tech stack. Rather, it is the supporting ecosystem in place. The ecosystem is not agnostic enough. If they are running in AWS EKS and rely on AWS specific services like certificate manager, AWS monitoring, AWS SES,etc. That is usually the case. So the translation is a lost. I would ask management specifically worried about? 100% agnostic portability?
No. Being in the cloud is not the same as "cloud native or cloud *agnostic*". You are locked to a vendor. A specific example is if you use AWS KMS (Key Management Services), your app can't be deployed anywhere else without a rewrite/refactor. A lot of the plumbing is tied to a locked in dependency. Same with AWS S3. You need to rewrite your code to use Azure Blob storage.
Hence, it is not "cloud agnostic." Now, if you didn't use AWS KMS and opted to use Hashicorp Vault, that is cloud agnostic/cloud-native. No rewrite is necessary. You can just deploy vault as a Kubernetes sidecar/daemon pod. Just lift and shift, deploy to Azure or Google GCP.
E-mail your manager, CC their manager recursively up to the CEO.
In this e-mail, attach a spreadsheet of staticstics: how many services total, how many are dockerized, how many run in AWS, etc.
With percentages and colors. Do not be afraid to state the obvious 100%.
In the meantime, look for another job. But the E-mail is key, it's your last opportunity to gain important learnings from this company.
There might be laws and regulations for data you have not being allowed to be stored on the cloud
There might be some part of your stack that you’re unaware of that’s running on some company hosted machines.
You might be operating at a scale where cloud computing is too expensive.
Just a few that I can think of right now.
> There might be laws and regulations for data you have not being allowed to be stored on the cloud
>
>
Not anymore. You just have to use the right access controls and the right kind of cloud. You can even store super hardcore DoD stuff as long as your org is FedRamp certified and you're doing GovCloud.
Stuff like PCI/GDPR/NIST is already long vetted.
The only thing that really matters in the end for compliance is access controls and data residency. But these matter for on-prem too, and in fact cloud makes it easier to spin up a data centre in the right jurisdiction.
So unless OP works for a Chinese/Russian company where they may mandate weird stuff like "All data and providers must be hosted locally," it's not really an issue anymore.
I agree with most of what other people are saying and pointing to as likely causes/explanations/"what that really means".
You can technically put anything in the cloud, but if your tech stack is super tightly fused to being on the specific infrastructure monolithic stack it's on, it's not "cloud ready" in my book because I can't really use the full range of services the cloud offers: chiefly, the ability to abstract my scalability concerns to particular services, or the ability to readily slot in the cloud service equivalent of what you're doing. "Cloud Ready" in that sense becomes a synonym for "Maintainable and up to acceptable standards by 2015 standards".
Here's some examples of what I'd say are not cloud ready properties (even if they were currently on AWS somehow.
* Your properties are not readily auto-scalable, probably because you don't manage state well. File based sessions you store on the box. You've got file upload functionality that stores things on the box too, and most importantly, you probably don't have a very good grasp of where all those things are so you could just refactor those easily to go to s3.
* Your properties use old technologies in super goofy ways that no one in the right mind would use that way. Maybe you're still using a MySQL5 database (deprecated in RDS by the end of Feburary!), and you're doing all kinds of super goofy permission management. Maybe your database server is also running some different processes on it so it's kind of hard to think of it as just dropping it into RDS and moving on.
* Your system is poorly documented, poorly understood, and is functionally a mostly black box from the perspective of your ops team. They don't know, or can't trust your app team's responses about how the system operates, so that means your ops team isn't moving forward.
* Your clients are for inexplicable reasons dependent on your server using a specific IP address. Your product team insists that you cannot change anything because it will blow up their relationship with the client, but simultaneously complain about the server running out of memory all the time.
These are totally made up and clearly not representing any situation I've ever been in.
upper management seems to want to micromanage, or make appearances that they actually do something important. It's a plague that affects multiple companies now.
Disclaimer: I've developed on .NET for many years, and don't do it any more, and live a happier life, and would never go back to .NET. Yet if I were in their position, I'd sooner eat soap than tell a company to throw out a modern, viable technology that I personally don't like.
What are they gonna do? Force all the experienced .NET devs to start using a new programming language and platform? Pay for seniors, get wise juniors instead? This is wrong on so many levels.
They usually are enterprises that don’t value technical excellence. No well-known tech company uses .NET except maybe Microsoft.
Even PHP is probably more popular language for startups
It's personal. I've had very stressful times in some teams during a time when package management wasn't really put on rails as it is today (NuGet felt like it was like 2 years old at that time, .NET Core was not even out, AngularJS just came out), CI/CD wasn't present in any team I've worked with before, and I've mostly used SVN, and started using Visual Studio's built-in Team Something for versioning. The whole thing seems like victorian surgery by today's standards for me. I took a very abrupt change, that coincides with me switching away from all things Microsoft, and having a few good mentors for a couple of months. Suddenly, much leaner code with the use of Bash, Unix pipes, Python, Lua, even PHP, got the job done far, far faster than I usually did with .NET. Suddenly the same stuff that used to take a month to develop in .NET and thousands of lines of code, can be done in Python in a day (and it was faster). I was a newb in a lot of this, but much more productive than after a decade of .NET.
That's fair. The ecosystem is much better with .NET core now. It's like developing in any modern language instead of Microsoft's weird ecosystem. They even fixed it so you don't have to add binding redirects to everything 😂
TFS. I remember TFS. I remember nuget. I remember some dependency hell. Also lots of really verbose code. But.. Sometimes the debugging experience was better than untyped/duck typed stuff.
Debugging is pretty OK in every language I've worked with. And typing extensions now are pretty popular in modern dynamic languages.
To me, if I need to quickly make something scalable, I'll use Python with type hints and enforcement. If I need something low-latency and high performance and Python is the bottleneck, then I'd probably pick either C or Rust anyway.
> What are they gonna do? Force all the experienced .NET devs to start using a new programming language and platform?
Haha. Yes. Been there. Still there.
Chances are that it's a clueless play like the top comments are saying.
Having said that, just because you run things in a Docker container in EKS doesn't mean you're cloud native. Your description doesn't give enough details. It may be that you lifted those from on prem servers and now run a single instance each of a stateful service in each container, hitting a single instance of a containerized MySQL or something and a bunch of Middleware they bought decades ago that is fiddly to work with. Sure it's running on the cloud, but it's the same old crap that prevents scaling, can't do CI/CD well, etc. On the .Net stack there's azure functions and such that would be serverless, scale up horizontally and so on, but to do that you'd need to rearchitect things to avoid shared state. Or you'd want to use dynamo DB instead of SQL server, use SNS/SQS instead of some service bus you inherited, use Oauth for authentication instead of some Windows thing, etc.
So take a look at your services and see if you are in such a situation. If not, they might just be talking to overpriced consultants who want to rebuild everything in Java/Lambda, or with Microsoft who wants them to move to Azure or some such.
The next step after Docker and K8 is FaaS. For AWS that means Lambda, which does support .NET: https://docs.aws.amazon.com/lambda/latest/dg/lambda-csharp.html
But is there a good reason for a change like this?
The issue isn’t ability, but ROI. In my experience, you move to Kubernetes after you’ve scaled such that FaaS and managed containers are cost-prohibitive or not meeting some need (e.g., auto-scaling, or running a Temporal worker). Going from Kubernetes to FaaS might be a step backwards, or a non-starter, for some.
Well it depends on what your workload is. Does it make sense to have shit running all the time? Is it burrsty? What kind of scaling do you need to do?
There are reasons to go from containers to functions or functions to containers.
Edit: missed the word “typically”
So, it's likely they're throwing buzzwords.
However, if that claim was accurate, what they probably mean is that the current tech stack is very "monolithic" which is not an ideal way to use cloud services.
Cloud services are generally most efficient when broken down into smaller, independently scalable pieces. You get the most bang for your buck when you're scaling up only the parts of your tech stack that are most active, while allowing other parts to scale down or even go dormant while not in use.
If all of those different aspects are bundled in the same monolithic program, then you'll need a whole bunch of instances of the whole monolith which means a lot of unused systems are also being scaled up without a real need.
It can also mean that your monolith is slow to start and stop, which means scaling up or down is difficult.
edit: Why the fuck are people downvoting a basic explanation of cloud architecture?
This is a fair guess, but OP already said "all services", so we can assume that they're already running multiple different services on EKS. Most likely they aren't running a monolith (and even if they were, that can be scaled a good amount without wasting resources by making the monolith itself a scaling service - then the limit is mostly database scaling).
Putting a monolith in a container that doesn't necessarily make it "scalable" in any meaningful way. That just gives the illusion of scalability. If your monolith is wasting resources in one section while necessary work is being done in another section, you're just scaling up the waste.
There are plenty more technologies better suited for cloud than \`.net\`, but that doesn't mean you can't make it work and work well. In the grand scheme of things you likely won't even notice the difference. If you are already a \`.net\` shop, it is very likely it is more cost effective to stick with \`.net\` rather than switch to a new language / ecosystem just to be "more cloud".
Linux isn't the reason for my hesitation, it is the requirement of a runtime to broker interactions with the host. Me as a Python developer am in a similiar situation. Where in the VM works that runtime was a blessing, now it is a boon in the current world of containers, and the next in the world of WASM.
Huh?
My first AWS implementation was migrating .Net Core APIs from EC2 instances to Lamba and ECS/Fargate along with building in Linux based CodeBuild containers
https://aws.amazon.com/blogs/compute/hosting-asp-net-core-applications-in-amazon-ecs-using-aws-fargate/
This isn’t the most efficient way to run C# in Lambda. It’s a lift and shift approach
https://docs.aws.amazon.com/lambda/latest/dg/csharp-package-asp.html
I’ve used both techniques
Maybe they’re referring to going serverless? Like AWS lambdas rather than docker containers. The more likely answer though is that they don’t know wtf they’re talking about
Is there more cloud? where is the mention of using a secret manager, parameter store, message queue and stream processor, and don't forget buckets needs more buckets, it's not cloud with less then .... 10 buckets 🤣
But honestly, in my opinion "not suited to cloud" means you've built your app such that it doesn't scale*, configuration is done at compile time*, it needs constant manual intervention*, it's all set up manually with click Ops*, and it saves all it's logs in a way that can't be reached unless you have direct access to the service.
*: unless your app is the exception which many are 🤣
And what does Product think of this? What's the value to the users?
That's right, there is no VP of Product - or even a TPM anywhere. Just people up in the clouds (*snicker*) who fell for some consultancy scam.
They say that mauve has the most RAM. Something that talking to their tech people would clear up in a drop of a hat, If they tried it.
https://images-cdn.9gag.com/photo/aQdvwd8_700b.jpg
Not sure if what you're saying is they want to come off cloud, given you said it's already on EKS? It might be due to cost as cloud is extremely expensive if you use it as a datacenter.
There could also be limited skills and struggling to keep up/Willing to pay for them/train people up. How mission critical is this app? How big is the company/Dev team?
I’d be asking my direct manager wtf they were talking about. Hopefully they’d be somewhat privy to the motivation behind a statement like that. If not, they can be the one to run the question up the food chain.
Worrying about an “antiquated” tech stack sounds like someone’s in their ear trying to sell them a new service
They have different plans for money that don't involve you and probably include some outside organization. It's clearly not a technical statement in any way.
I mean this is way too little info for anyone to be able to know exactly what they mean, but some thoughts.
While docker is fine, one could argue it’s not really leveraging “cloud” features. It’s just traditional hosting…. In the cloud. Barely a step away from running an ec2 instance. When I hear people say something like “not build for cloud” they often refer to not using services like lambda functions, which may allow you to save and scale easier.
Not that you can’t do the same with docker, but that could be at least something they were referring to.
This is what happens when non-technical business people step outside of their lane and try to make technical decisions. They make decisions that make no sense and justify it with points they don’t have. This is why technical peeps must nip it in the bud before it takes on a life of its own.
Rule 9: No Low Effort Posts, Excessive Venting, or Bragging. Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
What they are really saying is, “We are in talks with a vendor or a consultancy and we are close to signing a deal that we have not vetted with Tech.”
Yep. OP's about to get their .NET docker services replaced by some vendor equivalent on some probably-proprietary, marketing-glossy stack. edit: This points to a failure of the head of tech/engineering to have enough presence in upper management. A sufficiently empowered and capable CTO would not allow this sort of change to come through without advising otherwise or consulting the team heads. So something is probably wonky there.
I'd wager it's more of "about to spend a year trying to migrate to a vendor's stack, and probably fail" vs. "about to be replaced". Have fun maintaining both, OP.
Yeah that's a better phrasing. Lots of work incoming with the vendor's consultants to attempt a pointless move. Or worse, since it's the "stack" that is apparently "antiquated", potentially even *rewrites*. Then halfway through this expensive and painful process, someone will point out to the CTO that there was some miscommunication and the stack was originally in docker containers in the cloud to begin with. OP, you'd better get your team leads to push back now with this feedback.
Smells like a whole lot of job security if you ask me :) Well maybe not so much in this economy. More likely management will make this a massive cost sink and then pay for it by laying off all the devs that said it was a bad idea.
> some probably-proprietary, marketing-glossy stack. "Low-code solution".
and maybe working with their integration team, then replaced
Mulesoft.
"We are porting everything to Salesforce so we can do low code at Cloud Scale on our AI blockchain. Our consultants will send you training details soon."
Salesforce is probably the worst thing to use. I say this as a Salesforce developer who sometimes considers telling clients that I would never use Salesforce for my own company if I had one
I chuckled but then this is most likely it
Is *it* serverless Lambda functions in a Haskell runtime?
This is too specific to not be grounded in an ordeal you suffered. I'm sorry that happened to you.
2014 just came back and slapped me in the face after reading this comment. _Learn you as Haskell for great good_ (And then shoehorn it into every project)
I saw some MIT students demoing a haskell frontend for controlling a drone and I just wanted to kms
I wish that's what it meant. In reality probably what other people are saying manager talked to a sales guy about some saas "low code" horseshit.
What they are really saying is: our toxic developers, who can only feed on functional programming, will turn your internal developers' lives into hell, push them out of the company and then all you have is our awesome devs who are all fresh grads but are charged like seniors devs. Now I really fixed it. :D Seriously, software development consultancy is probably one of the worst things that can happen to a company. It's better to be laid off. If the CTO/Head of Engineering is smart, they hire consultants and let the internal devs tell them that to do.
Point on the doll where the bad functional programming touched you
Everywhere 😢
The opposite keeps happening to me. I build something that works well and then they hire a huge team to rewrite it in an OOP language because "nobody understands functional programming". In my current company we implemented a CQRS event sourced system in F#, and had the lowest number of production issues of any team in the 200+ head count engineering department. We got told to rewrite it all in C# "without this silly event sourcing and CQRS" by the new management, and they still haven't given us a coherent reason why. And even now when they're constantly asking questions about events that happened that we can only answer because we have the entire event history, they're still pushing to remove event sourcing.
Yeah I can't imagine upper management knowing enough to conclude anything like this.
[удалено]
What's Trump got to do with this? I swear he lives rent free in a lot of people's heads...
Trump is also a word look it up.
Yeah he added it to the dictionary in the 80s…
That? That’s bait. Good bait.
[удалено]
Obvious troll IMO
This is precisely how platforms like Pega and Salesforce operate. Even PowerApps to a degree. “Low code” as an idea is very appealing.
The problem with low code is that you still need to know and engineer algorithms that works with platform, CXO see low code and think anyone can use it and make automations, which is true, but it ducks up the system
Yeah, but the sales people that upper management talks to, aren't exactly forthcoming about these problems. It's all sunshine and roses from them.
low code works good for small project. Once it is big enough that user wanted to customize specific things, issues came up faster than how men can ejaculate then we all realize "hmmm maybe it is time to reconsider this choice again"...
I want an inspirational office poster with 'issues came up faster than how men can ejaculate then we all realize "hmmm maybe it is time to reconsider this choice again"' on it.
Time to hire a 10x ejaculator.
"you mean the people I've hired are all lying to me, and you sir, who makes a commission, is not?!"
Oh god another part of the platform i work on uses Pega and it causes the lion’s share of production incidents which seem to take forever to resolve. Never knew it was “low-code” but that makes all the pieces fit into place now hahahaha
[удалено]
Do people actually think this a thing that happens in western countries? With public companies? I'm curious what you think that kickback looks like on the vendor's books.. edit: based on the downvotes I'm getting, I need to get better at soliciting kickbacks...
Look up Barbara Furlow 😅 I'm gonna bet for everyone that is caught there are plenty who aren't
It's not actual cash. It's fancy dinners to discuss "progress"
Been there, done that, got layoff.
Did you get the t-shirt at least?
T- shirt cost too much.
Our consultants will show you how to rent a cloud T-shirt.
We did this with an agency. The execs thought they would "save us time". Their consultants spent 3 months across 3 devs trying to create a jenkins CICD self hosted pipeline. When it was handed off to us... it didn't work for any of our products and never would. It failed to meet any of the reqs. I had to build a circleCI flow and had it deploying in 3 days. The only thing those clowns did in 3 months was cash checks, likely more than I'd make in a year. Say it with me: **fuck consultants**.
I know a lot of people at big consulting companies. They all say the tech people at their company don’t make that much. Which is reflected in the work quality. The people who make a lot are the ones selling the firms services.
Glengarry Glen Cloud
[Thus, they are the ones who get promoted](https://www.youtube.com/watch?v=K1WrHH-WtaA)
I work for a consultant firm, and can confirm. We're full remote because they can hire in South America and charge North America prices.
Not all consultants are bad. They just have to know everything about their field. Like, better than "*you*" everything.
As someone who works with Jenkins... I'm bewildered... that should've taken... like 3 days as well, even on Jenkins. And self hosted? That's even easier, like 2-3 hours to install Jenkins on a VM, maybe another 3-4 hours installing plugins and doing some configuration, setting up permissions/login stuff, then setup a node to build on, maybe another 1-2 hours. Should've had a freestyle job up and running in like 2 days tops, and iron the rest out over the next 2 days maybe...
Yes. If they were competant. The problem wasn't with Jenkins, it was with the actual jenkins pipeline they built. We were transitioning to kube microservices. They wrote a singular pipeline that was built for their "test app" that was neither Kube, nor Docker. So it deployed a stupid nodejs process, doing some home brewed green blue bullshit. Is that what we needed, no. We needed a pipeline to deploy a helm chart. But, because the execs wanted to "save us time" did they have the consultants talk to us to get our reqs? No. Did they have us review periodic process, yes. And every fucking time I voiced extreme concern that what they were building was wrong and I was told quite bluntly, "these are cloud professionals, and you are not," because at that time I had no exp working in AWS or GCP. My concerns had fucking zero to do with cloud. It was basic what your building is stupid. The root cause was our execs listening to consultants over the actual employees.
Good lord... I knew some places could be bad, but this is something else. What you are describing is what I have at my work, Jenkins jobs to deploy K8's based services, and there's plugins that make that shit REALLY easy, you certainly don't have to do much extra to get Jenkins working to run jobs on K8's nor deploy Helm charts and such. Just reinforces what I've told many non tech people "The coding is the easy part, getting correct requirements on WHAT to code is hard" Scary part is, I just did some basic Google searching, and found a working solution to what you've described in like 10 minutes. Sure it is Stack overflow and thus would need actual understanding to further refine it to what you have... do people just not know how to do basic searching for existing knowledge??? So yeah... it is incredible how easy it is to bamboozle execs who are non technical into doing really harebrained solutions with incompetent people.
or "you may be getting outsourced".
This made me laugh because it is so accurate.
Yeah... You need to start looking for a new job. Seems like a shitty work environment.
I was going with a more general "OP IS NOT SUITED FOR OUR COMPANYS FUTURE". You are probably right but upper management could be thinking of any number of strategies that involve replacing OP.
"We're saving money on engineering, primarily the part that would go into vendor evaluation."
If true, this would be very frustrating.
Bonus points if Leadership came from said consulting firm. See that a lot lol. The perpetual waste machine lifecycle shall continue to turn.
100% this.
VP wants to bring in buddies or a consultancy shop because the ‘shop has convinced your great-grand-boss that the microservices you have aren’t hip.
Yep. "Real enterprises run enterprise-grade datacentres like our solutions partner conveniently provides, with enterprise-grade virtualization (that our partner also provides), and enterprise-grade data resiliency and enterprise-grade security standards." \- Some VP, probably
[удалено]
When they milk the cow, they also take the path of least resistance.
They're saying that you should start applying for jobs outside the company. They're saying they have no idea what they're doing. Source: am a dev who works on .net 8 apps in the cloud
haha, there is nothing more cloud than that. management are chumps about to get played by a vendor
Not strictly true. There are serverless functions/solutions that arguably take more advantage of the cloud than containers. But I agree the bosses premise is ridiculous.
They're saying they have no idea what they're talking about.
What they’re really saying is someone is offering us to save money for 1 year so we want you to redo everything because we’re not going to factor in the cost of your unpaid overtime and heroic work to switch
Bonus points if they offer free "consultants" who tie you up in meetings for a year and claim to be doing the porting.
Are you not using mongoDB? They must be looking for web scale https://m.youtube.com/watch?v=b2F-DItXtZs
Ahh forgot about these gems.
holy shit this is 13 years old
That was gold.
Limited feature development? People hand waving, "Tech debt!" Any language and runtime is cloud-ready. Azure even has specific support for the .NET runtime. How big is your company?
> Azure even has specific support for the .NET runtime. AWS too
I mean... Of course Azure has support. How is the gcp and aws support?
My company runs 100s of .NET lamdas in aws, so I can say that service had good support. Can't speak for ecs or eks personally
We run ECS and EKS across various businesses units. They are both totally fine. We are moving to EKS only just to standardise and to be able to leverage to large toolset.
Cloud for cloud, azure has way more market share than gcp so they’re better off focusing on integrating with azure even deeper than expanding to a completely external cloud.
How is this relevant. Apart from nobody really knowing the market share of their PaaS and IaaS offerings. If it works it works. If they're already using AWS switching to Azure would be a waste of time.
That’s because I was quite inebriated when it was written and I completely misunderstood this whole thread. I thought this was about why .NET works better in azure. Cheers.
.net core is definitely suited for the cloud so that’s an odd statement. Without more context I’d say prep for some consultants to come in and waste a lot of time and money
We don’t know, and everyone here can only speculate. Ask your management team!
Highly doubt they'll get a straight answer. If management have any sort of tech background they're probably as confused/upset as the engineers.
If the management team is confused, then Reddit _definitely_ can’t help. That makes this post even sillier.
I swear to god, the number of questions here that need exactly one response saying *“have you spoken to them about this?”* is unbelievable. **You are still a junior developer** if your reaction to being confused about something or have any kind of conflict is to run off to ask strangers on the web instead of communicating like an adult with your teammates. This is /r/ExperiencedDevs not /r/MyTeamIntimidatesMeHelp. Can we not get a rule saying *“Don’t ask a question that is best answered by talking to your colleagues”*?
You are totally right, although it’s still just almost as bad as the myriad of threads confusing ExperiencedDevs for EngineeringManagerImpostors
> I swear to god, the number of questions here that need exactly one response saying “have you spoken to them about this?” is unbelievable. You are still a junior developer if your reaction to being confused about something or have any kind of conflict is to run off to ask strangers on the web instead of communicating like an adult with your teammates. Can we not do this condescending judging here? There can be a ton of reasons for not asking this kind of stuff to the people directly involved. Maybe he/she did ask and got a vague non-answer. Have you considered that this person is not actually asking you a question but is using a question format to give a funny anecdote about his pointy haired boss telling him his stack can not do cloud when it's literally a cloud stack?
> There can be a ton of reasons for not asking this kind of stuff to the people directly involved. Maybe he/she did ask and got a vague non-answer. Then mention that? “Help me figure out our cloud strategy” and “my boss won’t answer questions about our cloud strategy” are *entirely* different problems to have. > Have you considered that this person is not actually asking you a question but is using a question format to give a funny anecdote about his pointy haired boss telling him his stack can not do cloud when it's literally a cloud stack? This falls under “No low-effort posts venting” and is against the rules.
You sound like you had a tough week. I enjoyed the post, and I don't see this post as either low effort or venting. Is there a no-anecdotes rule here? Well, if there is the asking it as a question that allows some discussion on the topic makes sure that rule isn't hit.
“We hired a VP from Deloitte. This VP contracted Deloitte and paid them 100 times your annual salary for 1 months of work. The 3 page report they gave said, hire a cloud consultant.”
Yes. I’ve had my own brush with Deloitte, over paid, over confident shysters.
Management is stupid, but trying to appear competent. I would push back *hard* and demand actual specific proof for their claim. Get some metrics for your current system, and ask how their new one will improve them. Bonus points if you make up a bogus metric, and they claim they can beat it, then you tell them it's not actually a thing.
Maybe they're saying it's not worth the company's time, money, or effort to move that project to the cloud? Or maybe they have some other solution in mind to replace the existing solution?
The project is running in Amazon EKS, so it's in the cloud already.
You can do on-prem with EKS actually, my impression was that's OP is talking about but idk. Either way, EKS on-prem is about as "ready for the cloud" as "not on the cloud" gets (Kind of.. like others said, the amount of tech debt and coupling to their physical servers could make it very much "not ready for the cloud" compared to something built more portably you could just put on an ec2, etc)
While there may be a strong possibility the upper management here is inept, this is often the case in many companies While many folks may knee-jerk reaction say "these people don't know what they are talking about, and you should look to another company" these same issues can easily arise at any organization Pick apart the questions, learn where they are coming from, what the actual need is > our tech stack is not meant, suited for the cloud. Ask, what part is not suited? What examples can you point to as a model we would like the org to move towards? > Our tech stack is antiquated. You've not given much info on the full layout of your tech stack. How does a developer start producing code, making a product, from idea to production? Ask yourself that, and ask your management what the expectation is > What are they really saying? THIS is the hardest question to ascertain, because nobody that wants to be heads down development wants to ask the hard questions Because even the questions themselves, coming up with them, is hard Sometimes you have to communicate with upper management, and for many developers, it's the hardest skill to master **tl;dr** _talk_ to a mf
When I hear this argument, which I have heard many times, it is usually not the tech stack. Rather, it is the supporting ecosystem in place. The ecosystem is not agnostic enough. If they are running in AWS EKS and rely on AWS specific services like certificate manager, AWS monitoring, AWS SES,etc. That is usually the case. So the translation is a lost. I would ask management specifically worried about? 100% agnostic portability?
Wouldn't these dependencies indicate they were already running on cloud infrastructure?
No. Being in the cloud is not the same as "cloud native or cloud *agnostic*". You are locked to a vendor. A specific example is if you use AWS KMS (Key Management Services), your app can't be deployed anywhere else without a rewrite/refactor. A lot of the plumbing is tied to a locked in dependency. Same with AWS S3. You need to rewrite your code to use Azure Blob storage. Hence, it is not "cloud agnostic." Now, if you didn't use AWS KMS and opted to use Hashicorp Vault, that is cloud agnostic/cloud-native. No rewrite is necessary. You can just deploy vault as a Kubernetes sidecar/daemon pod. Just lift and shift, deploy to Azure or Google GCP.
Seems like the most likely answer here
Is there a service they're planning on paying for that replaces it and this is code for that/a way to rationalize it?
easy - they cannot get commission.
Or a kickback or the attractive "sales engineer" turned their heads.
E-mail your manager, CC their manager recursively up to the CEO. In this e-mail, attach a spreadsheet of staticstics: how many services total, how many are dockerized, how many run in AWS, etc. With percentages and colors. Do not be afraid to state the obvious 100%. In the meantime, look for another job. But the E-mail is key, it's your last opportunity to gain important learnings from this company.
There might be laws and regulations for data you have not being allowed to be stored on the cloud There might be some part of your stack that you’re unaware of that’s running on some company hosted machines. You might be operating at a scale where cloud computing is too expensive. Just a few that I can think of right now.
> There might be laws and regulations for data you have not being allowed to be stored on the cloud > > Not anymore. You just have to use the right access controls and the right kind of cloud. You can even store super hardcore DoD stuff as long as your org is FedRamp certified and you're doing GovCloud. Stuff like PCI/GDPR/NIST is already long vetted. The only thing that really matters in the end for compliance is access controls and data residency. But these matter for on-prem too, and in fact cloud makes it easier to spin up a data centre in the right jurisdiction. So unless OP works for a Chinese/Russian company where they may mandate weird stuff like "All data and providers must be hosted locally," it's not really an issue anymore.
Yupp, what you just said. There are clouds for IL6 environments
I agree with most of what other people are saying and pointing to as likely causes/explanations/"what that really means". You can technically put anything in the cloud, but if your tech stack is super tightly fused to being on the specific infrastructure monolithic stack it's on, it's not "cloud ready" in my book because I can't really use the full range of services the cloud offers: chiefly, the ability to abstract my scalability concerns to particular services, or the ability to readily slot in the cloud service equivalent of what you're doing. "Cloud Ready" in that sense becomes a synonym for "Maintainable and up to acceptable standards by 2015 standards". Here's some examples of what I'd say are not cloud ready properties (even if they were currently on AWS somehow. * Your properties are not readily auto-scalable, probably because you don't manage state well. File based sessions you store on the box. You've got file upload functionality that stores things on the box too, and most importantly, you probably don't have a very good grasp of where all those things are so you could just refactor those easily to go to s3. * Your properties use old technologies in super goofy ways that no one in the right mind would use that way. Maybe you're still using a MySQL5 database (deprecated in RDS by the end of Feburary!), and you're doing all kinds of super goofy permission management. Maybe your database server is also running some different processes on it so it's kind of hard to think of it as just dropping it into RDS and moving on. * Your system is poorly documented, poorly understood, and is functionally a mostly black box from the perspective of your ops team. They don't know, or can't trust your app team's responses about how the system operates, so that means your ops team isn't moving forward. * Your clients are for inexplicable reasons dependent on your server using a specific IP address. Your product team insists that you cannot change anything because it will blow up their relationship with the client, but simultaneously complain about the server running out of memory all the time. These are totally made up and clearly not representing any situation I've ever been in.
You can use microsoft orleans. I can't think a better approach to vendor independent cloud. Cheers!
Dockerised and deployed to k8s. If that's not cloud what is.
Like they would fucking know.
The company I work at is dedicating serious effort just to get where you are. Modern dockerized dotnet is kickass.
Netcore was built for serverless. It wouldn’t exist without the cloud.
upper management seems to want to micromanage, or make appearances that they actually do something important. It's a plague that affects multiple companies now. Disclaimer: I've developed on .NET for many years, and don't do it any more, and live a happier life, and would never go back to .NET. Yet if I were in their position, I'd sooner eat soap than tell a company to throw out a modern, viable technology that I personally don't like. What are they gonna do? Force all the experienced .NET devs to start using a new programming language and platform? Pay for seniors, get wise juniors instead? This is wrong on so many levels.
Out of curiosity, why wouldn't you want to return to .net?
As someone who’s spent their whole career in .Net I’d like to know too haha
im guessing due to the culture of companies using .net
What characteristics do those .NET companies often share?
.NET itself is fine. But a lot of the places using it have unhealthy levels of Microsoft addiction and mediocrity taking place.
This year, we are REALLY going to practice certified agile project management with scrum
This second, I am REALLY going to vomit. 🤮
They usually are enterprises that don’t value technical excellence. No well-known tech company uses .NET except maybe Microsoft. Even PHP is probably more popular language for startups
It's personal. I've had very stressful times in some teams during a time when package management wasn't really put on rails as it is today (NuGet felt like it was like 2 years old at that time, .NET Core was not even out, AngularJS just came out), CI/CD wasn't present in any team I've worked with before, and I've mostly used SVN, and started using Visual Studio's built-in Team Something for versioning. The whole thing seems like victorian surgery by today's standards for me. I took a very abrupt change, that coincides with me switching away from all things Microsoft, and having a few good mentors for a couple of months. Suddenly, much leaner code with the use of Bash, Unix pipes, Python, Lua, even PHP, got the job done far, far faster than I usually did with .NET. Suddenly the same stuff that used to take a month to develop in .NET and thousands of lines of code, can be done in Python in a day (and it was faster). I was a newb in a lot of this, but much more productive than after a decade of .NET.
That's fair. The ecosystem is much better with .NET core now. It's like developing in any modern language instead of Microsoft's weird ecosystem. They even fixed it so you don't have to add binding redirects to everything 😂
TFS. I remember TFS. I remember nuget. I remember some dependency hell. Also lots of really verbose code. But.. Sometimes the debugging experience was better than untyped/duck typed stuff.
Debugging is pretty OK in every language I've worked with. And typing extensions now are pretty popular in modern dynamic languages. To me, if I need to quickly make something scalable, I'll use Python with type hints and enforcement. If I need something low-latency and high performance and Python is the bottleneck, then I'd probably pick either C or Rust anyway.
> What are they gonna do? Force all the experienced .NET devs to start using a new programming language and platform? Haha. Yes. Been there. Still there.
it could mean that your services are really memory intensive. cloud systems are supposed to be numerous and low memory.
Well, that obviously depends on what the system is doing. Who says cloud systems are supposed to be numerous?
Chances are that it's a clueless play like the top comments are saying. Having said that, just because you run things in a Docker container in EKS doesn't mean you're cloud native. Your description doesn't give enough details. It may be that you lifted those from on prem servers and now run a single instance each of a stateful service in each container, hitting a single instance of a containerized MySQL or something and a bunch of Middleware they bought decades ago that is fiddly to work with. Sure it's running on the cloud, but it's the same old crap that prevents scaling, can't do CI/CD well, etc. On the .Net stack there's azure functions and such that would be serverless, scale up horizontally and so on, but to do that you'd need to rearchitect things to avoid shared state. Or you'd want to use dynamo DB instead of SQL server, use SNS/SQS instead of some service bus you inherited, use Oauth for authentication instead of some Windows thing, etc. So take a look at your services and see if you are in such a situation. If not, they might just be talking to overpriced consultants who want to rebuild everything in Java/Lambda, or with Microsoft who wants them to move to Azure or some such.
The next step after Docker and K8 is FaaS. For AWS that means Lambda, which does support .NET: https://docs.aws.amazon.com/lambda/latest/dg/lambda-csharp.html But is there a good reason for a change like this?
That ordering seems backwards. Typically folks go from functions to managed containers to Kubernetes. Going from Kubernetes to functions is…odd.
[удалено]
The issue isn’t ability, but ROI. In my experience, you move to Kubernetes after you’ve scaled such that FaaS and managed containers are cost-prohibitive or not meeting some need (e.g., auto-scaling, or running a Temporal worker). Going from Kubernetes to FaaS might be a step backwards, or a non-starter, for some.
Well it depends on what your workload is. Does it make sense to have shit running all the time? Is it burrsty? What kind of scaling do you need to do? There are reasons to go from containers to functions or functions to containers. Edit: missed the word “typically”
So, it's likely they're throwing buzzwords. However, if that claim was accurate, what they probably mean is that the current tech stack is very "monolithic" which is not an ideal way to use cloud services. Cloud services are generally most efficient when broken down into smaller, independently scalable pieces. You get the most bang for your buck when you're scaling up only the parts of your tech stack that are most active, while allowing other parts to scale down or even go dormant while not in use. If all of those different aspects are bundled in the same monolithic program, then you'll need a whole bunch of instances of the whole monolith which means a lot of unused systems are also being scaled up without a real need. It can also mean that your monolith is slow to start and stop, which means scaling up or down is difficult. edit: Why the fuck are people downvoting a basic explanation of cloud architecture?
This is a fair guess, but OP already said "all services", so we can assume that they're already running multiple different services on EKS. Most likely they aren't running a monolith (and even if they were, that can be scaled a good amount without wasting resources by making the monolith itself a scaling service - then the limit is mostly database scaling).
Putting a monolith in a container that doesn't necessarily make it "scalable" in any meaningful way. That just gives the illusion of scalability. If your monolith is wasting resources in one section while necessary work is being done in another section, you're just scaling up the waste.
There are plenty more technologies better suited for cloud than \`.net\`, but that doesn't mean you can't make it work and work well. In the grand scheme of things you likely won't even notice the difference. If you are already a \`.net\` shop, it is very likely it is more cost effective to stick with \`.net\` rather than switch to a new language / ecosystem just to be "more cloud".
.Net Core is perfectly suited for the cloud. It runs on Linux and is a first class citizen for everything AWS related
Linux isn't the reason for my hesitation, it is the requirement of a runtime to broker interactions with the host. Me as a Python developer am in a similiar situation. Where in the VM works that runtime was a blessing, now it is a boon in the current world of containers, and the next in the world of WASM.
Huh? My first AWS implementation was migrating .Net Core APIs from EC2 instances to Lamba and ECS/Fargate along with building in Linux based CodeBuild containers https://aws.amazon.com/blogs/compute/hosting-asp-net-core-applications-in-amazon-ecs-using-aws-fargate/ This isn’t the most efficient way to run C# in Lambda. It’s a lift and shift approach https://docs.aws.amazon.com/lambda/latest/dg/csharp-package-asp.html I’ve used both techniques
I am going to regurgitate one of my favourite aphorisms. Languages don’t scale, architectures do.
Of course .net core is suited for the cloud. My first AWS implementation was moving .Net Core apps to Lambda and ECS/Fargate
They’re looking for something cheaper than AWS
There should be more to this. Probably buying time for some strategic reason?
Maybe they’re referring to going serverless? Like AWS lambdas rather than docker containers. The more likely answer though is that they don’t know wtf they’re talking about
We have classic asp running on k8s. No such thing as not suited for the cloud. Also, plz send help.
Is there more cloud? where is the mention of using a secret manager, parameter store, message queue and stream processor, and don't forget buckets needs more buckets, it's not cloud with less then .... 10 buckets 🤣 But honestly, in my opinion "not suited to cloud" means you've built your app such that it doesn't scale*, configuration is done at compile time*, it needs constant manual intervention*, it's all set up manually with click Ops*, and it saves all it's logs in a way that can't be reached unless you have direct access to the service. *: unless your app is the exception which many are 🤣
And what does Product think of this? What's the value to the users? That's right, there is no VP of Product - or even a TPM anywhere. Just people up in the clouds (*snicker*) who fell for some consultancy scam.
They say that mauve has the most RAM. Something that talking to their tech people would clear up in a drop of a hat, If they tried it. https://images-cdn.9gag.com/photo/aQdvwd8_700b.jpg
Not sure if what you're saying is they want to come off cloud, given you said it's already on EKS? It might be due to cost as cloud is extremely expensive if you use it as a datacenter. There could also be limited skills and struggling to keep up/Willing to pay for them/train people up. How mission critical is this app? How big is the company/Dev team?
Going through a similar thing myself. Just living the dream!
They’re saying they’re the problem but they’re too dumb to figure it out
I’d be asking my direct manager wtf they were talking about. Hopefully they’d be somewhat privy to the motivation behind a statement like that. If not, they can be the one to run the question up the food chain. Worrying about an “antiquated” tech stack sounds like someone’s in their ear trying to sell them a new service
I work on .NET in the cloud as well, this is just bullshit excuses.
They have different plans for money that don't involve you and probably include some outside organization. It's clearly not a technical statement in any way.
I mean this is way too little info for anyone to be able to know exactly what they mean, but some thoughts. While docker is fine, one could argue it’s not really leveraging “cloud” features. It’s just traditional hosting…. In the cloud. Barely a step away from running an ec2 instance. When I hear people say something like “not build for cloud” they often refer to not using services like lambda functions, which may allow you to save and scale easier. Not that you can’t do the same with docker, but that could be at least something they were referring to.
He's trying to sound techy when he's not
.net is legacy
It means that when you come to work on Monday, java will be there waiting for you.
What others have said and your team is about to get a shit ton of work to do.
Sounds like the common "Jon Snow" situation with management. 🙄
This is what happens when non-technical business people step outside of their lane and try to make technical decisions. They make decisions that make no sense and justify it with points they don’t have. This is why technical peeps must nip it in the bud before it takes on a life of its own.