Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm beginning to investigate service-oriented architectures and wonder how best to structure the messaging between processes. It seems that direct HTTP calls between services and/or a pubsub bus are two common approaches. In what sorts of situations is one more favorable than the other? I can see how pubsub would lead to more decoupled services but I also get the impression that it becomes much harder to track a message's path though the system.
What are some resources for learning more about this? I'm particularly curious about this in the context of very small, "hand-rolled" services (i.e. Ruby/Sinatra, Node/Express, Redis pubsub, etc.) as opposed to any of the prescribed SOA stacks/suites out there...though I'm sure the same principles apply.
Thanks!
I'll give you my two cents.
but I also get the impression that it becomes much harder to track a message's path though the system.
You're right that pubsub SOA architectures AKA (SOA 2.0) providing a great deal of decoupling, but you also pay a price, because this is exactly what happens, although tools like splunk can help a lot.
seems that direct HTTP calls between services and/or a pubsub bus are two common approaches
Actually if you look at the most used .net event soa frameworks (NServiceBus, Mule and MassTransit) they don't use http calls, but yes you can implement a microservices architecture and use http as the communication protocol.
I understand you want to start applying some of the best enterprise architecture concepts but I would say that you better off starting with simpler, yet stronger foundations. There is no point in you jumping to event soa, without knowing if you really need it. If I was starting a new system and wanted to make sure that I was properly adapting DDD and SOA principles, I would start by identifying the services for my domain. So say you have 3 services, you could start by declaring the public contracts for each of those services, you don't need anything special, you can start with WCF/ASP.NET Web API with a sync REST API. You would then make sure that each service would get its own database, because you're aiming for low coupling, and you could then create an API layer (the one visible to the outside world) again using WCF/ASP.NET Web API, because your microservices should not be exposed directly to the outside world. So at this point you would have a SOA like, yet simple in design, architecture, but because you would have well defined contracts, you could well extend your services by adding async capabilities to them and for that you would start by adding a message queue to each of the services. You know, you don't need to start with a complex system, start with something basic, well defined, which allows you to scale if you have to.
The system I described could be extended to support events easily if you wanted to, and the fact that you would at this point have already sync messages would not stop you from adding asyn messages to the system as well.
But these are just my two cents.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am creating a MVP(Minimum Viable Product) that has a nodejs server using express for a rest api and a socket.io connection for chat features.
My concern is not so much about cost or scalability, but about setup time/maintenance as this is an MVP. Would serverless or not serverless take less time to setup/maintain on AWS?
Serverless is a great choice is you want to set up a simple REST API application. Using Express would also be a good choice.
API Gateway and Serverless also now supports websockets, so it should be pretty easy to create a websocket application. When it comes to socket.io, however, you will need to do a bit of research before diving in.
Websocket support on API Gateway is a relatively new concept, and there aren't too many resources online on it. The combination with Lambda can be a little difficult to grasp at first. As for socket.io there are even less.
I personally recommend running a EC2 instance running socket.io for your MVP. I think it'd be easier.
There are several reasons to choose a serverless infrastructure over non-serverless. In many cases these align very closely with 5 Pillars of the AWS Well-Architected Framework. Serverless architectures offer great:
Reliability - no need to guess capacity, can easily scale horizontally with demand
Efficiency - tremendously reduced costs for intermittent and infrequent workloads
Maintenance - nonexistent
Availability - highly available and fault tolerant
While your proposed project does appear to fit well within the FaaS framework (infrequent and unpredictable workload with low resource requirements), the disadvantages of serverless, notably the more complex and difficult to test architecture and vendor lock-in can make it challenging to rapidly prototype and deploy a MVP.
As your product favors an engineering tradeoff toward time to market, a non-serverless approach will most likely enable you to release a MVP quickly with minimal headache
There are some serverless frameworks that work on AWS lambda function. By my realworld experience, there are some notices on each of them:
AWS Amplify (https://docs.amplify.aws) a full stack serverless solution for developers. It's quite easy to use at the begining. Cons. Is that over the time your maintainance cost is higher on deployment part. It's very slow to deploy a stack on AWS when you just need to change a piece of code. It will download all the stack files to local then upload again...
Serverless framework (https://www.serverless.com) is less complex, rich plugins and nano function oriented. The downside of this framework is every code function will be used the same across lambdas. When the project is bigger, the code size is bigger therefore your lambda's cold start is slower.
Simplify framework (https://github.com/simplify-framework/codegen) sounds a lightweight but rich functionalities. It allows you build your CI/CD inside your project. This concept is similar with AWS CDK has just released a couple of days in May. You design your API using OpenAPI specs (swagger specs) that will be reused and standardized your APIs across tools and processes. No vender lock-in has been desiged carefully. Today you are in AWS but tomorrow it will be on your on-premise servers.
You choose what fits to your solution. There is no one fit all.
I'm an architect in a large scale financial company and we are in the beginning of implementing a new business oriented infosystem across our different countries.
From the very early on the core idea has been to follow microservice oriented principles as much as possible (and making sure engineers have read Building Microservices book by Sam Newman).
By now I've come to crossroads. Our services are primarily JSON REST services using Swagger for automated documentation, but in order to use these services in our business processes and making sure not to write business logic into services outside the domain of those services, we've been using Camunda as an orchestration tool. And Camunda is fine (though some have considered Corezoid as an alternative), but somewhat clumsy in what is an otherwise an elegant set of services.
Now service orchestration is a concept pretty familiar to most engineers. But it is one that I am not entirely happy with due to still having a central engine that drives everything. It is incredibly expensive to replace later down the road (though still cheaper to replace than a monolith). And even if this central engine is split into multiple engines (which is actually the case today), it does not necessarily make it much better.
In recent years there has been a movement with microservices towards choreographed (close to event-driven) architecture. It is at this point where I am looking for advice from engineers and architects who have faced similar crossroad decision points.
I absolutely love the idea of decoupled architecture and despite feeling good about killing monoliths and having elegant independent services, I still detect a lot of dependencies in business process as a whole in current orchestrated solution in where it should not actually exist.
And it's not like we are avoiding events. We have actually implemented events on our architecture as well in order to decouple many processes with the core principle that if you don't need a synchronized response and just need to notify of something happening to initiate another process an event is put up that may be caught by another process that starts executing. And orchestration is easier to explain and visualize, it is easier to tweak and modify by more technical minded business users. And I think it is easier to test and validate from business perspective. Orchestrated architecture like this also (usually) expects a good service discovery and quality automated documentation and non-functional requirements which are all things I value greatly.
All of those things that are a question to me in choreographed approach since I don't have first-hand experience in running this in large scale - just some local test prototypes.
But I think you see where I am coming from. I'm trying to consider alternatives without having to regret driving the company all the other way in the end.
Perhaps you can share your own experience with a similar situation or share an interesting link or two? Or am I looking for a silver bullet that doesn't exist yet?
Services need to interact - services that don't interact are not part of the same system. The search needs access to the catalog, the cart doesn't get the price info from the page, the account needs the purchase history, the recommender needs purchase history, the cart needs to verify the currently available coupons, the inventory needs to know something was purchased etc.
Service boundaries are set to minimize the needed interactions. It can make sense to cut a service to smaller components but if they share a database (internal structure) they are different aspects of the service.
When services interact it creates a level of coupling - at the least, this coupling is some API (JSON or otherwise) that the service has to "maintain" for so other services can interact with it.
Another coupling type is temporal coupling - which is what you get in request-reply situations (and you can eliminate in event driven systems) However, Orchestration vs. Choreography is not about these differences (even though orchestration is mostly associated with request/reply) - it is about central control and governance vs.flexibility and serendipity.
Orchestration has risks like migrating business logic out of services into the orchestration while choreography runs the risk of chaos. By the way, direct request/reply integration has the worst of both worlds but wins on simplicity when systems are small enough.
Choosing between the two is a balancing act (like most architectural decisions) for instance, Netflix built on choreography for a lot of time but then found they need some control back and introduced an orchestration engine. Nothing is a silver bullet :)
Personally, I like choreography better because of the reduced coupling and flexibility and favor tools like open Zipkin to bring some order into the chaos.
You can see a partial example for an orchestration based arch in slides 10-22 of a presentation I did about microservices
I think I understand where you're coming from, having recently redesigned a system to a "microservices" architecture. I like (and use) the approach by these guys: http://scs-architecture.org/
The main point is, that you try to avoid cross-dependencies between you "services", which basically makes choreography obsolete. The hard part is decomposing your problem domain into chunks which do not need eachother for any of the executed business-cases. They may need different kinds of data that may or may not be "shared", as in present in multiple systems, but they don't need synchronous calls between them for any given business case.
This is quite different from what Netflix is doing for example. Those guys/gals are doing chain-calling through different layers of services, each adding its logic to the "process". This model might fit in some cases, and probably fits in Netflix's case. But it may not be necessary for you.
The ideal Self-Contained System would be completely independent of other Self-Contained Systems, would cover one or more highly cohesive business functions (in full depth from the UI to Persistence!), and would be not calling any other system synchronously. The ideal system would let the client "orchestrate", by just offering links through its Web (HTML) interface.
Think more like Amazon. The "Landing Page" is a different application than the "Search", which is still different from the "Checkout". They are completely different, sometimes even look a bit different! Integrated by links and forms in HTML, not explicitly orchestrated.
This might be what you are looking for.
Some warnings: First instinct of some people is to have "Customer" microservice, or "Product Repository" microservice, and similar. This will not lead to Self-Contained Systems, as you will need synchronous calls to these things, making them essentially "central" components. The key is to split the business domain, so bounded contexts a la Eric Evans.
When building a microservice oriented application, i wonder what could be the appropriate microservice granularity.
Let's image an application consisting of:
A set of various resources types where each resource map a given business model. (ex: In a todo app resources could be User, TodoList and TodoItem...)
Each of those resources are saved within a NoSQL database that could be replicated.
Each of those resources are exposed through a REST Api
The application manage an internal chat room.
An Api gateway for gathering chat room and REST api interaction.
The application front end: an SPA application connected to the API Gateway
The first (and naive) approach when thinking about how microservices could match the need of this application would be:
One monolith service for managing EVERY resources and business logic:
By managing i mean providing the REST API for all of those resources and handling the persistance of those resources within the database.
One service for each Database replica.
One service providing the internal chat room using websocket or whatever.
One service for Authentification.
One service for the api gateway.
One service serving the static assets for the SPA front end.
An other approach could be to split service 1 into as many service as business models exist in the system. (let's call those services resource services)
I wonder what are the benefit of this second approach.
In fact i see a lot of downsides with this approach:
Need to setup an inter service communication process.
When requesting a service representing resource X that have a relation with resource Y, a lot more work are needed (i.e: interservice request)
More devops work.
More difficulty to share common code between resource services.
Where to put business logic ?
When starting a fresh project this second approach seams to me a bit of an over engineered work.
I feel like starting with the first approach and THEN split the monolith resource service into several specific services depending on the observed needs will minimize the complexity and risks.
What's your opinions regarding that ?
Is there any best practices ?
Thanks a lot !
The first approach is not microservice way, by definition.
And yes, idea is to split - each service for Bounded Context - One for Users, one for Inventory, Todo things etc etc.
The idea of microservices, at very simple, assumes:
You want to pay extra dev-ops work for modularity, and complete/as much as possible removal of dependencies between different bounded contexts (see dev/product/pjm teams).
It's idea lies around ownership, modularity, allowing separate teams develop their own piece of code, without requirement from them to know the rest of the system . As long as there is Umbiqutious Language (common set of conventions/communication protocols/terminology/documentation) they can work in completeley isolated, autotonmous fashion.
Maintaining, managing, testing, and develpoing become much faster - in cost of initial dev-ops and sophisticated architecture engeneering investment.
Sharing code should be minimal, and if required, could be done to represent the Umbiqutious Language (common communication interface/set of conventions). Sharing well-documented code, which acts as integration/infrastructure mini-framework, and have special dev/dev-ops/team attached to it ccould be easy business, as long as it, as i said, well-documented, and threated as separate architecture-related sub-project.
Properly engeneered Microservice architecture could lessen maintenance and development times by huge margin, but it requires quite serious reason to use it (there lot of reasons, and lots of articles on that, I wont start it here) and quite serious engeneering investment at start.
It brings modularity, concept of ownership, de-coupling of different contexts of your app.
My personal advise check if you really need MS architecture. If you can not invest engenerring though and dev-ops effort at start and do not have proper reasons for such system - why bother?
If you do need MS, i would really advise against the first method. You will develop wrong thing's, will miss the true challenges of MS, and could end with huge refactor, which could take more work than engeneering MS system from start properly. It's like to make square to make it fit into round bucket later.
Now answering your question title: granularity. (your question body bit different from your post title).
Attach it to Domain Model / Bounded Context. You can make meaty services at start, in order to avoid complex distributed transactions.
First just answer question if you need them in your design/architecture?
If not, probably you did a good design.
Passing reference ids between models from different microservices should suffice, and if not, try to rethink if more of complex transactions could be avoided.
If your system have unavoidable amount of distributed trasnactions, perhaps look towards using/making some CQRS mini-framework as your "shared code infrastructure component" / communication protocol.
It is the key problem of the microservices or any other SOA approach. It is where the theory meets the reality. In general you should not force the microservices architecture for the sake of it. This should rather naturally come from functional decomposition (top-down) and operational, technological, dev-ops needs (bottom-up). First approach is closer to what you would need to do, however at the first step do not focus so much on the technology aspect. Ask yourself why would you need to implement a separate service for particular business function. Treat it as a micro-application with all its technical resources. Ask yourself if there is reason to implement particular function as a full-stack app.
Some, of the functionalities you have mentioned in scenario 1) are naturally ok, such as 'authentication' service - this is probably good candidate.
For the business functions decomposition into separate service, focus on the 'dependencies' problem, if there are too many dependencies and you see that you have to implement bigger chunk of data mode - naturally this is not a micro service any more.
Try to put litmus test , if you can 'turn off' particular functionality and the system still makes sense - it is the candidate for service or further decomposition
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I would like to know the differences between Mashery, WSO2 and 3scale. Someone who has used API Managers before can give his opinion? What are advantages and disadvantages of each one
thanks
cheers
Not sure, but this question might end up flagged as off topic - vendor comparison, but anyway I'll jump in. I work at 3scale (full disclosure) but hopefully this is useful anyway - the three are pretty different. Trying to be as neutral as possible!:
3scale uses NGNIX and/or open source code plugins to enforce all of the API traffic rules and limits (rate limits, key security, oauth, analytics, switching apps on and off etc.) and the traffic always flows directly to your servers (not via the cloud) so you don't have additional latency or privacy concerns. Because it's NGNIX it's also widely supported, very fast and flexible. Then it has a SAAS backend that manages all the analytics, rate limits, policies, developer portal, alerts etc. + synchronizes across all the traffic manager nodes. It's free to use up to nearly 5million API calls per month.
WSO2's system is an additional module to the WSO2 ESB so if you're using that it makes a lot of sense. It runs everything locally with no cloud components - a pro or a con depending on how you see it. It's also been around a lot less time and doesn't have such a large userbase.
Mashery has two systems - the main one with which the API traffic flows through Mashery's cloud systems first and has traffic management applied there. So there is always a latency heavy roundtrip between the users of the API and your servers + it means Mashery is in your API traffic critical path. They also have an on premise traffic manager but it's much less widely used. Both solutions have very significant costs and long term commitments.
As 3scale what we see as the main advantage is you have a tons of control as to how you set up all the traffic flow and never have to route through a third party plus you have the benefit if having all the heavy lifting hosted and synchronized across multiple data centers. We're also committed to having a strong free for ever tier of service since we want to see a lot of APIs out there! http://www.3scale.net/
Good luck with your choice!
steve.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Attended an interesting demo on REST today, however, I couldn't think of a single reason (nor was one presented) why REST is in anyway better or simpler to use and implement than a SOAP based Services stack.
What are some of the reasons Why anyone in the "real world" use REST instead of the SOAP based Services?
Less overhead (no SOAP envelope to wrap every call in)
Less duplication (HTTP already represents operations like DELETE, PUT, GET, etc. that have to otherwise be represented in a SOAP envelope).
More standardized - HTTP operations are well understood and operate consistently. Some SOAP implementations can get finicky.
More human readable and testable (harder to test SOAP with just a browser).
Don't need to use XML (well you kind of don't have to for SOAP either but it hardly makes sense since you're already doing parsing of the envelope).
Libraries have made SOAP (kind of) easy. But you are abstracting away a lot of redundancy underneath as I have noted. yes in theory SOAP can go over other transports so as to avoid riding atop a layer doing similar things, but in reality just about all SOAP work you'll ever do is over HTTP.
RESTful services are much simpler to consume than SOAP based (regular) services. The reason for this is that REST is based on normal HTTP requests which enables intent to be inferred from the type of request being made (GET = retrive, POST = write, DELETE = remove, etc...) and is completely stateless. On the other hand you could argue that it is less flexible as it does away with the concept of a message envelope that contains request context.
In my experience SOAP has been preferred for services within the enterprise and REST has been preferred for services that are exposed as public APIs.
With tools like WCF in the .NET framework it is very trivial to implement a service as REST or SOAP.
Some relevant reading:
Amazon Web Services Blog: REST vs SOAP
Dare Obasanjo writes often about REST
I'll assume that when you say "web services" you mean SOAP and the WS-* set of standards. (Otherwise, I could argue that REST services are "web services".)
The canonical argument is that REST services are a closer match to the design of the web - that is, the design of HTTP and associated infrastructure. Thus, using a REST service will be more compatible with existing web tools and techniques.
Of course, once you drill into specifics, you find out that both approaches have strengths in different scenarios. Is it those specifics that you're interested in?
The overhead isn't that important as good architecture.
REST isn't a protocol it is an architecture that encourage good scalable design.
It is often chosen because too much freedom in RPC can easily lead to a poor design.
The other reason is predictable cost of RESTful protocols over HTTP because it can leverage existing technologies (mainly proxies).
RPC initial cost is quite low but it tend to increase significantly with load intensification.
REST is implementation-agnostic and much more transparent, and this makes it great for public APIs, especially for big websites like Flickr, Amazon or Digg that are using their APIs as marketing tools and really want people to consume their data. They don't want to be hand-holding 1000s of novice developers who are trying to debug their scripting language of choice's buggy SOAP library.
Versus SOAP and WSDL, which are better for internal applications, where you have drop-in libraries and known clueful people on both ends. (And you maybe don't have to care about things like Internet-scale load-balancing, HTTP caching etc.) Then you get APIs that are self-documented, preserve types etc. with zero work.
Got to read Roy Fielding's most excellent dissertation on the topic. He makes an excellent case and was definitely WAY ahead of his time when he wrote it (2000).
Steve Vinoski's blog and his latest articles are definitely worth perusing. He's a former CORBA guru, who wrote probably the best book on the subject with Michi Henning, "Advanced CORBA® Programming with C++". However, he has since seen the error of his client/server ways, and now swears by REST.
REST allows your non-mutating operations (that generally use the GET verb) to be cached. That is, cached by the client and/or cached by proxies. This can be a huge win!
REST is basically just a way to implement web services. It is just a way to use HTTP correctly to query the web services you are trying to hit.
http://www.xfront.com/REST-Web-Services.html
http://en.wikipedia.org/wiki/Representational_State_Transfer
It is super simple and slim. You could do it with browser via http verb: GET.
I haven't find a browser can manually do generic http POST request easily
Here's one data point: Amazon offers its APIs in both REST and SOAP formats and 85% of the usage is REST.
REST is easier to implement, easier to understand and higher performance.