Hacker Newsnew | past | comments | ask | show | jobs | submit | slad's commentslogin

I have been using Windsurf for few months. They even have their own AI model SWE-1 model. I really liked using Windsurf. They also have integrations with other IDEs ex: jetbrains, VS code, etc.

This week I have been using Claude Code and Windsurf side by side. I would make change with one, stash it, ask the other for similar change and then would diff it.

Overall Windsurf was pretty on a par with Claude code.


I’m curious what email service you ended up using? I have been thinking to move out of gmail but it just feels like there isn’t good free alternative and also task of changing email address everywhere seems like behemoth task.


I have worked at several companies with SOA. In fact, I was lead at one of the companies where we were breaking monolith to smaller services. We were having lots of issues with scalability with monolith. First we tried breaking to scale it horizontally by creating shards and routing users to different shards. That helped but with the growth we were seeing, we were back to scaling issue in 14 months. We broke it further into 4 shards and started working on SOA. After year and half we had dozens of smaller services and scaling was really smaller problem as it boiled down to scaling specific service. Over all, few points to add for without regards to SOA that I didn’t see here in threads -

- smaller blast radius: every change is small and specific to service so easy to rollback and understand the impact

- load tests: capacity management was relatively easy; small services with small dependencies

- easier to update dependencies: java version updates was not huge project with every feature development on hold

- autonomy: team had more autonomy as it didn’t require committee approvals

- prolific design patterns: services could use different architectural patterns

This obviously came with lot of other issues - latencies, cross service atomocity, logs correlation. But at the end I believe pros outweigh the cons and I would continue to use SOA pattern wherever I could.

Industry has been trending towards microservices/lambdas which in my opinion take it too far. Finding that balance between Monolith and micro service is what works in my opinion.


I work at a company that uses a hybrid monolith/service approach to serve millions and millions and millions of users. Unless you work for one of the top-top-top social networks we probably serve many more users that your systems do.

And even our existing services are not "micro": they are relatively large, and were mostly extracted to handle tasks that needed a different language.

This massive code base is a very good example of how most people can do just fine with a monolith. I even learned to appreciate this uniform approach to things: monorepo, unified ci/cd process, shared responsibility.


I don't think the number of users has as much to do with partitioning a system as the variety of required tasks does.


[flagged]


Yes, sure, we need better definitions and a limited scope.

I also don't think ppl would have a monolith vs numerous services discussion in HFT or MMO game development or a major search engine development context.

It seems that we're talking about typical web apps, shared mobile app backends, etc. I believe that most code developed with this use-case in mind doesn't have to know anything outside of the usual 3 layers: client-side, server-side (aka "the monolith) and a database backend.


It would appear to make sense to separate two things

- a service as isolated business logic with clean requirements process, ownership, SLAs, interfaces, testing, and build infra for maintenance

- a service as an endpoint you can access from most any environment (other services in whatever language, web apps)

The trick is to keep these two things apart and assign services to physical/virtual nodes/pods/whatever as late as possible rather than making deployment decisions through choosing implementation techniques. Eg it's not reasonable to expect scalability by deploying individual services to a large number of nodes with excessive granularity of services; having the option to deploy a called service on the same host as the calling service to have essentially no network overhead might make more sense. It's also not reasonable to attempt to scale out services to a large number of nodes when your bottleneck is an RDBMS or other storage.

This was already very clear with 2nd gen SOA architectures like SCA (service component architecture) around 2007 or so, with options for binding implementations to remote protocols (SOAP) or locally via procedure calls, or both at the same time. This separation is notably absent from microservice architectures which always want to produce a pod or vm image as result artifact.

Now SOAP (and SCA and other SOA frameworks) also allowed transactions and auth context propagation; something that isn't even on the radar of microservice-like approaches. The (many) ones I saw at customers at least only naively implemented the happy path, not allowing for two-phase commit or at least compensation services to be called on abort by an aggregating service.


You are so right here. Clearly you worked with enterprise distributed systems and learned the industry body of knowledge for that - things like configuration driven binding 'services' to 'host processes', distributed transactions or compensation, auth propogation, and advanced tooling for distributed development enabled by strong typing.

Alas most developers weren't aware of all these things that SOAP delivered.

.

Programming's Eternal September of the twenty first century has thrown the baby out with the bathwater - those unwashed masses didn't understand why SOAP was a wee bit complex, the very good reasons!

They RESTed instead of scrubbing up on their studying. They twittered and twattered instead of studying. In their multitudes they cast a POX of JSON on our world!

They weren't the strong silent type to refactor, to compensate and rollback their mistakes .. and that is why they renamed SOA to micro services .. to make the huge mess sound smaller than it really is ..

/s

okay okay I will get off my soapbox now


Don't forget POJSON services lol!


In your opinion what is the difference between an SOA and microservice architecture? When does a microservice become just an SOA service or vice versa?


I think the biggest difference is as defined by Martin Fowler:

" When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.

The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool."

https://martinfowler.com/articles/microservices.html#SmartEn...


Look this is a great answer, and I love Martin Fowler. That's one rational explanation. It may however be a rationalised explanation that misses out on the difference that makes a difference to understanding what's really going on.

So here's another perspective, that of a software anthropologist .. .

Common patterns of networked systems were developed over decades, and as it developed over decades it built various advanced features on top of the core network call/response features - service busses - routing - useful abstractions like decoupling services from host processes - propogating security contexts through the chains of service calls that can develop when these systems evolve - strong typing, which enabled layers of tooling to replace manually doing jobs with these systems and various advanced features.

That was called SOA, because it looks at software architecture as a set of services.

Then along came a bunch of programmers that weren't very studious, started from scratch just doing basic message passing without all the advanced features that had been built up by the decades of previous hard won lessons. That was called microservices. Note the removal of the 'architecture' from microservices!

slightly /s


> - prolific design patterns: services could use different architectural patterns

Very true.

But there is still a lot of architecture that crosses microservice boundaries: How the domain is split, the dependency hierarchy (or lack thereof) between services, data lifecycles, ...

It's important not to forget that.


I’m genuinely interested to know when containers should be used. I’m not ignorant and understand advantages - consistent env, run anywhere, fast startup time, etc. But there is also considerable cost involved with increased complexity, educating devs, hiring experienced DevOps, etc

I have over 15+ years of professional development experience and AWS experience and I understand the scale.

Our company has 20-30 instances used by 5-6 services. We use terraform/ansible to deploy infrastructure so deploys are pretty reliable and repeatable. So I am genuinely interested to understand if it’s worth going container route?


I don’t think you should move unless you expect your company will expand a lot. It seems like your scale is fairly modest, your setup works and users are happy. So it’s probably fine.

Advanced orchestration systems like kubernetes are very valuable if you want to do multiple deployments in the same day, across many different services, without losing your mind. It lets you move very very quickly... the time to build a docker container, push it up to a registry and switch your deployment to start using the updated version is ridiculously simple.

So it depends on what kind of shop you are and what your devs want. If they like to iterate rapidly, containers and kubernetes is a well known path to get there.


Interesting comments but curious to know from the perspective of racism and related issues. As an Immigrant from India, and Living in California (for over 10 years) at this time seems to be best bet from that perspective.

With expanding family, I have been contemplating a lot to move outside of CA for cost saving but thoughts about racial issues plaguing the country just makes me nervous.


Did you experience it yourself? I haven't heard many reports about racial violence against Indians.

As a white person, I occasionally experienced verbal aggression from Black people (didn't talk back, so it ended that way). I think the other way round is more or less a taboo these days.



How does having billionaires mean there is a large population that you can monetize?


Hey you just gave me an idea. An exclusive photo sharing app for people who are worth a billion dollars or more. I mean, how will those poor people show off their private mansions without attracting unnecessary scrutiny? Since the service has no need to scale, I will personally visit every billionaire to verify their identity when they join. And then I will start a bidding war amongst all the luxury goods makers to advertise on my network.

All I need to do now is to befriend a few billionaires.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: