noop_joe

Totally, I think there's a lot of retroactive justification for what's familiar whether it be microservice or monolith. They both have advantages and disadvantages -- we're at a point where deploying and running either is available on most clouds.

That said, I think interesting possibilities exist where the two approaches are blended. I work for a cloud [1] that supports a concept of "services" grouped within an app each of those services is a web server that can be configured to sleep [2] under specific conditions -- effectively serverless but without the loss of shared memory and all the efficiencies of running a more traditional web server.

The grouping of services also provides a way to spin off parts of an application while keeping it within the same deployment process.

1. https://noop.dev

2. https://noop.dev/docs/sleepy-services/

I don't know of an internal feedback tool, that's not more general purpose. I think a lot of what you're describing is the-practice-of-software-development. There are Lots of possible solutions, what works best for _your_ team will be somewhat unique to them.

The company I work for [0] provides application hosting which includes automatic preview URLs, that can also be associated with a Github PR. The PR will have a link to the environment, with discussion below. Subsequent releases to the environment also get registered with the PR so it's easy to catalogue and annotate developments/fixes.

0. https://noop.dev

As others have said, it depends a lot on the product. A lot of the people on PH are other people building stuff, if it makes sense to launch there, join some PH communities on LI. The more you're already engaged on PH, I think the better off you'll be.

I've found it's harder to read signals from ads for early stage releases. You need something to compare to... Then again, maybe a super narrow target with a very clear conversion might yield some useful engagement.

GL!

One of the most difficult challenges with incidents is dispelling the initial conjecture. Something bad happens and a lot of theories flood the discussion. Engineers work to prove or disprove those theories, but the story about one might take on a life of its own outside the dev team. What then ends up happening is post-incident there's a lot of work to not only show that the problem was the result of XYZ, but also it definitely wasn't the result of ABC.

I was responsible for wsj.com for a few years. The homepage, articles and section fronts were considered dial-tone services (cannot under any circumstances go down). My job was to lead the transition from the on-prem site to the redesigned cloud site. As you can imagine there were a few hiccups along that journey.

One particular incident we encountered was when reporters broke the news of a few unrelated industry computer system failures (including finance). Because it was about a financial system, people visited wsj, the spike in traffic was so large it knocked us out. Now other news outlets were reporting wsj down. Unfortunately, there was a perception that these incidents were all related by a coordinated hacking event.

Each minute the site had an interruption of service, I would need to spend hours post-incident making sure the causes were understood, verified and stakeholders knew what they were.

All in all, the on-call experiences were fine. Sure people were tired if they happened in them middle of the night, but the team was supportive and there was a culture of direct problem solving that didn't add _extra_ stress.

Fun stuff.

Noop [0] is a cloud platform that runs entire application ecosystems (including edge routing) locally and deploys the same setups globally -- it's a departure from the plug and play paradigm of kubernetes, but it means a lot less integration work. Full disclosure, I work @Noop.

0. https://noop.dev

Heroku and Reclaim are far from the only two options available. The appropriate choice depends entirely on the team's available expertise and the demands of the applications under development.

There's a lot of disagreements pitting one solution against another. Even if one hosting solution were better than another, the problem is there are SO MANY solutions that exist on so many axis of tradeoffs, it's determine an appropriate solution (heroku, reclaim, etc) without consideration to its application and context of use.

Heroku has all sorts of issues: super expensive, limited functionality, but if it happens to be what a developer team knows and works for their needs, heroku could save them lots of money even considering the high cost.

The same is true for reclaim. _If_ you're familiar with all of the tooling, you could host an application with more functionality for less money than heroku.

The company [0] I work for gave a talk on this [1]. We're going a bit beyond analyzing logs because we have more contextual information about running software so we can compare different application state over time and infer whether it appears the application is experiencing an "incident".

0. https://noop.dev

1. https://www.youtube.com/watch?v=PxZx71xfIl8

I agree with the storage example.

> A counter point is that being a professional software developer is more than shipping features, you have to ship something that is profitable in the long run, which requires you have a broader perspective than your desire for a narrow focus.

I think what's more common, particularly in mature companies, is that the responsibilities are getting split between those that manage the complexity of infrastructure and software developers. Software devs might dictate the infrastructure requirements in their own terms like systemA should have access to systemB, but they're not going to be setting up the Amazon security group.

To me, it's about finding the right level of abstraction. At some point we developers have to trust that the underlying system will do what it says it's going to do.

I guess what I'm wondering is more about the opposite of the "cool/neat" where orgs either prohibit development in non-standard langs (and that was good/bad) or allow development in non-standard langs (and that was good/bad).

What criteria is used to determine when it's ok to deviate from in-house langs? What justification is used to prevent deviation at all costs?

This sounds like software development

In areas where there's a decent amount of separation between the developers that made some application and the people responsible for running it, I can see a lot of use for AI. Especially for initial triage.

For larger-scale apps with lots of moving parts (ie microservices) simply speeding up attribution of issues before getting to actual diagnosis could be a major optimizer.

If I understand correctly, the benefit of using this over something like Compose is the parity with production.

In my experience Compose is great for local development, but doesn't hold up well for complex architectures in production.

I work for a company [0] building something similar, but mostly agnostic to programming language. One thing I particularly like about the approach is the reduction of time debugging pipeline issues. I find increasingly that that is where my time goes -- most unfortunate.

0. https://noop.dev

We're a developer platform [0], for running apps at scale and locally.

The platform is batteries included: global router, logs, metrics, managed resources (datbases, caches, block storage). Because we have all this data in a unified platform we can (already, without AI) correlate issues across different system components, reliably and without elaborate integration work. We're now taking that a step further and using LLMs to fulfill a portion of the support/operational role.

As it happens, we're hosting an event on these developments for NY Tech Week [1].

0. https://noop.dev

1. https://lu.ma/h015tm6c

To me this is just one of many infrastructureisms. Tools, platforms, etc are all leveraging metaphors that don't map well to the mental model of _application development_.

We are building an application/infra platform, Noop [0], it's multi-repo, one key benefit is it facilitates the deployment of different system components with greater isolation.

That said, I'm a big fan of mono-repo. Noop actually supports developing mono-repos in a really interesting way. Here's an example [1] Vue + Node backend in one app. It should be pretty straightforward to see how you might be able to extrapolate that to more services when needed by looking at the .noop/blueprint.yaml in the linked repo.

0. https://noop.dev 1. https://github.com/noop-inc/template-nodejs-vue

Have you considered using a provider that might help eliminate some of the operational burden of running your apps?

At a very high level, when using the big 3 and hosting that's raw infra you're going to find ways to pay for _keeping things running smoothly_. At least the big three have happy paths to avoid some of the operational burden (hidden among many many foot guns).

Full disclosure I work at noop.dev [1], a hosting provider trying to shift the focus of developers from infra-level abstractions to application-level abstractions.

I'm probably biased, but my instinct is that concerns over lock-in are totally valid, but the cost of avoiding is higher than the penalty of embracing.

1. https://noop.dev

Disclosure I work for a company, Noop [1], which is the picture of the steak.

As someone working on the marketing side of the endeavor, I see the shift the author describes. there are a handful of PaaS companies picking up where Heroku left off and in the enterprise world devops is evolving toward "platform engineering". Platform engineering suffers from being poorly defined, but there appears to be growing demand within large enterprises for something like internal-heroku. But there's still a problem.

To me, the problem is not kubernetes. The problem is that tooling has become so specialized that the focus of work has become integration between tools. And that cumulative integration work complicates the operational responsibilities of software developers. Even if you have a dedicated devops team, the complexity of those integrations flows down to developers in the form of different systems for logging, monitoring, firewall, cdn, ci/cd, secrets, etc.

1. https://noop.dev

For building docs sites I like Astro. There are at least a few tailwind+docs themes available if you want to get something started fast. By default all content is markdown, but you can integrate with other CMSs.

I think I used something called Spinal as a reference theme [1]

I use astro for the development of my company's developer docs [2] -- I would reach for it for internal sites also.

1. https://spinalcms.com/resources/astro-documentation-theme-wi... 2. https://noop.dev/docs/

edit: fix link

It might not matter _that much_ depending on the complexity of the application you're modeling.

There are lots of options. A few things to consider:

- Is it a dedicated individual or group responsible for the IaC? What are they comfortable with? - Details about the running app will need to find their way into the infra somehow (env vars at least), if it's a separate group or individual, what will be the most obvious process to perform that exchange of information?

I wrote a short piece about point two [1]. Disclosure: I work at a company building a platform with its own opinionated IaC.

1. https://noop.dev/blog/build-apps-not-infrastructure/

IaC is undeniably a good pattern for dealing with complex systems. The bigger problem is that it's not a solution for delineating responsibilities between software engineers and infrastructure engineers. All the specifics about an environment that need to make their way from software->infra (and in some cases the other way) still need to be worked out, and that's often a bigger problem than getting code to a box that always has access to a database (oversimplification).

I tried to outline some of these ideas in a post [0], full disclosure I work for a company solving this problem. Our approach is to treat IaC as _part of_ a broader abstraction for applications.

1. https://noop.dev/blog/build-apps-not-infrastructure/

I like restclient. There's no UI, just .http files with a simple format for describing requests. there's a version for emacs and vscode that are mostly interoperable.

We were using lima, but switched to directly interface with qemu. We were able to get better control for networking and lots of performance and status notification improvements.

Linked in parent is a blueprint which is how we define applications. That config can be used to stand up an application locally as well as in a cloud environment without additional configuration.

Full disclosure I work at a company [1] attempting to address this very problem.

Without dedicated devops the challenge is allocating developer time to do the integration work required to get the various ops tools playing nicely together. In my experience that work is non-trivial and eventually leads to some form of dedicated ops.

That is also part of a dynamic -- lots of tools available for solving these problems exist because of dedicated ops. It's not easy for a team trying to build software to also take on these extra operational responsibilities.

What we're trying to do is create a highly curated set of what we think of as application primitives. These primitives include CI/CD, Logs, Services, Resources etc. Because they're already integrated it doesn't require developers to figure out API keys, access control, data synchronization, etc.

1. https://noop.dev

I'm working on a developer platform [1] that makes the progression from local development to global deployment way smoother than alternatives.

At some point AI may have a role in the platform. But for now we're focused on much more fundamental problems related to the process of developing and scaling software applications.

BTW we're looking for developers to try it out!

1. https://noop.dev

To a large extent this is true. But a lot of the complexity is introduced as a way to deal with the operational effort of running software (HA, security, platform upgrades, backup/recovery, incident response, all that stuff). That doesn't mean it shouldn't be on a single server -- but a _lot_ of the motivation is preventing the dreaded 3am call.

Agreed. I'd add a good tool, one that helps developers be better developers, also needs to help them get from where they are today to the future where they're using that tool. As in, if the tool helps, but the hurdle to start using it is too high, it's not a good tool.

Does RDS have similar limitations to Heroku PG?

Is the problem portability or completeness?

I'd love to connect with you and talk more about this! I'm working for a company building something that addresses the problems you describe [1], ditto for pricing model.

email is in my bio :-)

1. https://noop.dev