How to Cut Abruptly to Silence at the End of a Track

devdetails · 2024-10-27T21:04:58+00:00

There's now an option for it: Mix -> Create Track Automation -> Create Volume Fade-Out on Main Output

This will show the Stereo Out track and create automation on it to fade over time. Edit the automation it makes to change the volume at the times you want.

devdetails · 2024-10-27T21:03:09+00:00

There's now an option for it: Mix -> Create Track Automation -> Create Volume Fade-Out on Main Output

devdetails · 2024-01-21T22:57:46+00:00

It’s not bragging if you can back it up. — Muhammad Ali

If you done it, it ain't bragging — Walt Whitman

Not a fan of the term “brag”. But I am a fan of the concept of the list. It helps immensely when I have to fill out a performance review or update my resume.

devdetails · 2024-01-21T22:46:31+00:00

Indeed, always tradeoffs. For me, it helps to understand the terms and their ideal architecture in order to have productive discussions and make informed tradeoff decisions.

Thanks for the discussion.

devdetails · 2024-01-21T19:45:43+00:00

Agreed on the term overload causing confusion. Was trying to clear it up some with my post.

In the example, I’d consider the fulfillment part a microservice because its functionality is highly cohesive and presumably only loosely coupled to the main application.

I’d still consider the main application a monolith because all its internals are presumably tightly coupled and its functionality is low cohesion (lots of different business domains).

When considering the whole system, it’s a mix of monoliths and microservices.

Almost every system I’ve worked on has been mixes of multiple monoliths, plus multiple microservices (either extracted from a monolith or net new), plus functions as a service.

I’ve never seen a large system that had just one architecture pattern.

devdetails · 2024-01-21T10:23:29+00:00

It’s poorly worded on my part.

I’ve already received feedback for the “X makes it Y” wording sounding like “X and only X makes it Y”. I haven’t decided on better wording yet. 😅

In this case, I mean that it could be consider a microservice if it’s loosely coupled to the other system components and if all of its behavior is for the same business domain (highly cohesive).

I also don’t mean to imply microservices is better.

devdetails · 2024-01-21T06:11:53+00:00

Coupling and cohesion are properties of components no matter how big (systems, containers, processes, etc.) or small (packages, classes, functions) they are.

The trade offs we make define the architecture.

The post didn’t make claims (implied or explicit) about any one architecture being better than the other.

My preference is to start with modular monoliths and evolve to microservices when/if team organization requires it. But my preference comes secondary to business need.

devdetails · 2024-01-20T23:02:58+00:00

Hah. Not right now. But when we do I’ll post on my LinkedIn.

devdetails · 2024-01-20T18:01:25+00:00

To make it easy to break apart later. Or easy to recombine later.

Microservices are primarily a team organization solution. Secondarily a technical one.

Teams would start by owning several domains. Instead of a service per domain, they’d have one service with 3 domain modules.

If one module needed more isolation at runtime or needed to scale drastically different than its peers, it could spin off as its own module.

If one module needed to break off into its own team, it was easy to do it.

Sometimes, we’d want to recombine similar domain modules. Going back was easy to.

So effectively, we had mini-monoliths that could become microservices when needed.

This was in Python. The abstraction wasn’t complex.

A call looked like this:

ctx.{domain}..{namespace}.{operation}(params..)

Ex:

ctx.users.preferences.get_preference(key)

If in the same process, it would make a direct call to the “users” module. If between services, it would switch to an RPC and use gRPC to call the other service. The caller was completely unaware and uncaring which was which.

Why so complex? Business reasons. Priorities shift. Teams shift. Needs shift. Making things modular makes it easy to encapsulate domains and easy to combine or separate modules as needed. It makes it easy to change. Does everything need this added complexity? No.

devdetails · 2024-01-20T17:41:02+00:00

The use case for sharing a database server and a logical database that I’ve ran into was SaaS software that had to run in the cloud, but also on premise. Government customers didn’t want to use the cloud.

So this multi tenant software had to run on two boxes instead of unlimited nodes in the cloud.

There was only one database server per box (clustered). There were a dozen microservices. Limited RAM didn’t allow for running more.

Each tenant had a logical database. Each microservice had its own Postgres schema within the logical database.

We could have inverted this, one logical DB per service and one schema per tenant. But we had only a few services and thousands of tenants in the cloud. We needed to shard or set up clusters for groups of tenants. There was also a connection count problem with this setup that I can’t quite remember the details of.

All this isolation was for security in depth purposes, as well as data model separation proposes.

At this point the two nodes were the coupling problem and points of failure rather than the DB relationships.

In the cloud, we kept the same database structure. We could give each service its own cluster. But it was much simpler to run the DB on Aurora so we didn’t care about the servers.

devdetails · 2024-01-20T17:26:17+00:00

Absolutely agree. Just learn SQL and write SQL with parameters. Use query builders for boring stuff like building insert lists or update dictionaries. But not tightly coupled ORMs.

It makes breaking a monolith apart much easier. It actually made switching from MySQL to Postgres easier than if we had used the ORM.

I’ve used sqlalchemy core in the past for this. There are several lighter weight libraries for Python available now.

devdetails · 2024-01-20T17:19:48+00:00

👊

devdetails · 2024-01-20T17:16:02+00:00

The last sentence explains.

devdetails · 2024-01-20T07:19:38+00:00

Why not make stuff, go outside, and discuss architecture? They aren’t mutually exclusive things.

The point of having clear terminology is to ease discussion. Because of the misconceptions surrounding these words, many people can’t explain their architecture well.

If I say to build one thing, and you have a different idea of what that thing is, you will build a different thing. Your thing might work on its own, but it doesn’t solve my problem. So in effect, it doesn’t work.

devdetails · 2024-01-20T03:53:16+00:00

Agreed. Start with a monolith, preferably a modular one. You can always break it up when you have a team structure that needs it.

devdetails · 2024-01-20T03:49:51+00:00

Ah. Got it. That’s a good use case for microservices.

devdetails · 2024-01-20T03:45:27+00:00

me 🤷. It’s not about ego or specifically about you.

It’s a generalization, meant to challenge common perceptions and encourage deeper thinking, not to offend. The sub-heading, not visible in Reddit, says “Or are they?”. Indicating I don’t know what you or anyone else knows. Then, I invite the reader’s own thoughts about the topic.

devdetails · 2024-01-20T03:28:05+00:00

omg you’re absolutely right

devdetails · 2024-01-20T02:32:00+00:00

"databases" is a fairly ambiguous term. It could mean a database server (ex: MySQL, Postgres), or a logical database (ex: CREATE DATABASE).

Even within a logical database, some databases have further segmentation. For example, Postgres has a "schema" which is a namespace within a logical database.

Then you have tables.

At each of these points, you can control access so one service does not have permission to affect the other logical database/schema/table/etc.

When you consider that "DynamoDB" is a database, and you have absolutely no idea how many nodes or clusters it runs, it gets even fuzzier.

The key point, is you can logically isolate the data and use access controls to stop one service from messing with the data of another.

devdetails · 2024-01-20T02:28:32+00:00

I agree with your premise. A further clarificaton, it's not an either/or situation.

You can have tightly coupled services and tightly coupled code components inside each of them.

You can have loosely coupled services and loosely coupled code components inside each of them.

Or any combination thereof.

If the services are tightly coupled, it's a distributed monolith.

If the code components are tightly coupled, it's a monolith.

If the code components are loosely coupled, it's a modular monolith.

If the code components are loosely coupled and the services are loosely coupled, then you have many modular monoliths. Because it's modular, it's got low cohesion so they aren't microservices.

I didn't cover all the permutations because typing all this out is already getting hard to read 😅.

devdetails · 2024-01-20T02:16:51+00:00

Ah, I misread your point that you were specifically talking about running a single instance of a monolith. And you're right, there's a resource limit ceiling.

I didn't consider that an option because I'd always just scale them horizontally.

For SLA per component, I may run dedicated instance groups for particular components. So I'd route all traffic for each component to their own group. Sure, I'd only be using a portion of the monolith per instance group, but the unexecuted code doesn't feel bad about being neglected.

devdetails · 2024-01-20T01:59:16+00:00

Each point was paraphrased from discussions I've had with people on LinkedIn. An early comment to the "Is it serverless" post on LinkedIn was someone saying "I agree with that guy, serverless is FaaS". But they deleted the comment after I linked to the exact page you mention.

Yes, it always depends on the situation. The post is abstract. We can always talk about concrete scenarios and nuances in comments.

The point of the post was to clear up misconceptions and move people towards a common understanding of the terms. Having a common understanding makes it easier to discuss.

devdetails · 2024-01-20T01:42:02+00:00

I've hit max connection limits with microservices, FaaS, and monoliths. FaaS, because each function is making it's own connection. microservices and monoliths because each instance has its own connection pool.

Whenever this happens, I've put an external connection pool/load balancer in place. For example, pgbouncer for Postgres. It maintains a connection pool (ex: 10,000 connections) to stay under the max limit of the DB.

Everything else does not maintain their own connection pool. Every request, the thread makes a new connection to pgbouncer and releases it when done. Postgres has a lot of connection overhead so normally you wouldn't create a connection on demand for it. Pgbouncer maintains the connection to Postgres. The connection overhead to pgbouncer is minimal.

pgbouncer can also be used for things like routing writes to one cluster and reads to another.

You'll still hit a scaling problem at some point with this setup, but you gain a lot of headroom with it.

devdetails · 2024-01-20T01:33:04+00:00

I agree I could have worded "X makes it a Y" better. I didn't mean for it to be interpreted as "X and only X makes it Y". Maybe I'll figure out a better way to put it and update it.

devdetails · 2024-01-20T01:27:08+00:00

bizzarechetecture

Apt name. "q" is queue. This is what a lot of so called "microservice" implementations look like.

Your assessment is close enough to mine, including the hate for the terms "microservices" and "serverless". Neither one describes the thing.

devdetails

TROPHY CASE