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 6 years ago.
Improve this question
I am trying to evaluate different web service frameworks for API development in .Net. So far the frameworks I've been looking at are:
ServiceStack
MVC
Web API
NancyFx
I'm trying to find some common talking-points between the frameworks so I know what to look for when picking a framework. The talking points I've got so far are:
The Framework beliefs and principles
The Architecture of the framework (Client and Service side)
The Stack the framework provides you with
The Ease of development within the stack (plugins etc)
End-to-end performance benchmarks
Scalability benchmarks
Framework documentation availability
Framework Support (Cross platform etc)
Pricing
Overall Conclusion
Can anyone think of anything else I should think about? By the end of the research I'm hoping to write about each framework in detail and to make comparisons as to which framework to chose for a given purpose. Any help would be greatly appreciated.
End to End Productivity - The core essence for a Service is to provide a Service that ultimately delivers some value to its consumers. Therefore the end-to-end productivity of consuming services should also be strongly considered as the ease of which Services can be consumed from clients and least effort to consume them, ultimately provides more value to clients which is often more valuable than the productivity of developing Services themselves since the value is multiplied across its multiple consumers. As many services constantly evolve, the development workflow of updating Services and how easy it is to determine what's changed (i.e. if they have a static API) also impacts productivity on the client.
Interoperability - Another goal of a Service is interoperability and how well Services can be consumed from heterogeneous environments, most Web Service Frameworks just do HTTP however in many cases in Intranet environments sending API requests via a MQ is more appropriate as it provides greater resilience than HTTP, time-decoupling, natural load-balancing, decoupled endpoints, improved messaging workflows and error recovery, etc. There are also many Enterprises (and Enterprise products) that still only support or mandate SOAP so having SOAP endpoints and supporting XSD/WSDL metadata can also be valuable.
Versionability - Some API designs are naturally better suited to versioning where evolving Services can be enhanced defensively without breaking existing Service Consumers.
Testability and Mockability - You'll also want to compare the ease of which Services can be tested and mocked to determine how easy it is to create integration tests and whether it requires new knowledge and infrastructure as well as how easy it supports parallel client development which is important when front and backend teams develop solutions in parallel where the API contracts of a Service can be designed and agreed upon prior to development to ensure it meets the necessary requirements before implementation, then the front and backend teams can implement them independently of each other. If the Services haven't been implemented the clients would need to "mock" the Service responses until they have, then later switch to use the real services once they've been implemented.
Learnability how intuitive it is to develop Services, the amount of cognitive and conceptual overhead required also affects productivity and the ability to reason about how a Service Framework works and what it does has an impact on your Solutions overall complexity and your teams ability to make informed implementation decisions that affect performance and scalability and the effort it takes to ramp up new developers to learn your solution.
Related
I am trying to understand the difference of SOA and microservices archtitecture and some terms are so abstract to me, so it is hard for me to understand.
I read documents, generally mentioning about;
Soa is enterprise scope
Microservice is application scope
I can not understand this concepts, what is the difference of enterrise scope and application scope?
is that when dividing applications into multi services ? in both architectures applications are divided into multiple services and pieces are communicating by similar technology.
if difference is about how to divide application into multiple services and in soa it should be divided by busineess concepts, I dont think that there is rule in microservices architecture about not dividing by business concepts about the size of each service.
another abstract thing that I met:
This integration must occur by using service interfaces in soa- that's why it is Service-oriented.
what does that mean ? and how it is different from microservices integration?
Thanks for any ideas,answers
It's been a long since the question was asked so not sure if the insights below are relevant to you anymore.
Enterprise scope with respect to SOA usually refers to Service enablement of existing applications in an enterprise and unlocking their potential/investment while creating an overarching Business Process. SOA is very tightly bonded to the Business process and in simple terms can be assumed to be the actual implementation of an end-to-end process such as Sales Order Processing, Loan Application approval. Keep in mind that to create such a process, the SOA process/application would need to integrate with heterogeneous applications/systems/databases such as ERP, CRM, RDBMS, File systems, etc. In that sense, SOA architecture is not a pure app development architecture. Another aspect of SOA that you already mentioned is Service interfaces which can range from SOAP, JMS, and all other kinds of protocols
Microservices on the other hand are more aligned towards hardcore application development and breaking applications into granular and independent components (many times, even written in different programming languages). But most often the primary integration mechanism is lightweight REST API between the microservices.
Hope it helps.
Ok, as far as I've understood both in SOA and in Microservices modules should be independant and reusable. But what really differs SOA and Microservices ?
Both rely on the services as the main component but a lot of differences there. Few are below
SOA:
Follows “share-as-much-as-possible” architecture approach
Supports multiple message protocols
Multi-threaded with more overheads to handle I/O
Maximizes application service reusability
Not focussed fully into DevOps / Continuous Delivery
MicroService:
Follows “share-as-little-as-possible” architecture approach
Uses lightweight protocols such as HTTP/REST & AMQP
Single-threaded usually with use of Event Loop features for non-locking I/O handling
More focused on decoupling
Strong focus on DevOps / Continuous Delivery
Microservices Architecture is not an invention. Enterprises such as Amazon, Netflix, and eBay used the divide and conquer strategy to functionally partition their monolithic applications into smaller units, and resolved many issues. Following the success of these companies, many other companies started adopting this as a common pattern to refactor their applications. Eventually the pattern was termed as Microservices Architecture. Nothing radically new has been introduced in MSA. MSA is the logical evolution of SOA and supports modern business use cases.
Microservices vs SOA: How Are They Different?
I tend to agree with Chris Richardson's[1] definition.
3 main areas where SOA and micro services diverge:
Inter process communication
SOA:
Smart pipes eg. ESB
Protocols - SOAP, WS*
Micro service:
Dumb pipes eg. Message broker
Protocols eg. REST, gRPC
Database
SOA:
Shared databases
Micro Service:
Databases per service
Services tend to be monolith in SOA whereas small in nature as micro services.
[1]: https://microservices.io/index.html
Taken from: https://www.digitalroadmap.management/blog/2019/11/19/what-are-microservices-and-what-is-soa-and-what-are-the-differences-7245k
SOA and microservices have much in common and at first sight, it seems that the latter is just a new hyped buzzword for what SOA has already described. Yet, there are some differences between both.
What are Microservices?
Let´s first look at what a microservice is. Although there is no common definition for what a microservice is, there are a couple of common characteristics that definitions of microservices share. Those are:
Microservices are small, individual and independent components of software that, together, make an application.
Microservices are business-oriented, which means that the software architecture focuses on business purposes, such as a business capability, a particular product or service.
Every microservice provides a small piece of software to a greater purpose. Therefore, microservices regularly communicate with each other when in operation.
A major purpose of microservices is that they can be developed and deployed independently from each other. This leads to a decentralization of development teams in practice, which enables them to develop and deploy faster and with less dependencies and constraints.
Due to the modular architecture and the increased amount of communication interfaces between the microservices, errors and failures can be analyzed more precisely. In addition, microservice architectures are usually designed in such a way that they still function in the case that single microservices provide errors.
A microservices architecture is often used in areas that are continuously developed further. In such environments, the advantages of independent development and deployment, as well as failure tolerance is of highest importance.
What is Service Oriented Architecture (SOA)?
SOA, which stands for Service Oriented Architecture, is a software architecture style where generic services are provided to other components in the same architecture that provide more complex services based on the shared generic services. In the end, it is similar to a company´s shared services center.
Let´s imagine the following situation: A company that is operating in different countries has no shared services center at the moment. Therefore, basic HR and Finance activities, such as payroll and accounting are done individually in every country. By implementing a shared services center, the company can send all requests related to those activities to one single point of contact where the activities are executed. When the task is finalized, the results are sent back to the individual country. The individual countries then use the results, adapt them to country rules or their individual workforce and provide an additional, more sophisticated, or more individual service to their customers. SOA works in a very similar way. It allows to extract basic services from individual applications and bundles them in a shared services module instead. This shared services module then executes the tasks and provides the results back to the individual applications, which use them further.
So let´s investigate what SOA and microservices have in common and what not.
What do Microservices and SOA have in Common?
Both enable an integration into the wider IT – in contrast to monolithic systems that have no integration outside their own boundaries. A monolithic system can be the better option in areas where security is highly important or where there are no synergies with other systems expected, however, with the broad adoption of cloud technology and the required scalability, integrated systems are usually the preferred solution for architects
Both try to identify independent pieces of software that can be applied in different contexts and environments. SOA does this with the help of services that deliver information from one to another system and microservices do this with APIs that provide standardized interfaces for communication
SOA can have very different scopes, from very small to very big. Unlike the name suggests, this is also true for microservices, which can be just the authentication of a user at a service or the full purchase process behind your e-commerce basket
What are the Differences Between Microservices and SOA?
The objective of SOA is to design systems as a set of loosely coupled services that enable the integration of applications. On the contrary, microservices have the objective to work on different platforms and in different environments that emerged due to the manifold cloud environments and mobile solutions that require to work on different operating systems.
SOA is not dynamic and cannot fit for different purposes. They must be adapted or redeveloped every time a critical architecture piece of the involved technology changes. On the contrary, microservices try to be more independent by building on standardized interfaces that are valid across different technologies. However, there are often different standards, which can in the end lead to the same challenge that SOA has.
SOA typically shares fundamental components across different services. On the contrary, microservices usually have everything they need within the service, duplicated in every single microservice. Microservices are hence a bit slower, but less dependent on underlying services in order to work.
SOA and microservices are quite similar concepts. Some might also argue that microservices are a particular type of SOA. In the end, SOA and microservices both have their purposes. SOA helps to interconnect large enterprise systems (e.g. an HR or ERP system) so that they can communicate and interchange data. In contrast to that, microservices have the goal to work in different environments and independent from those environments, such as on web-based systems, operating systems, or cloud environments.
The difference between them (from real-life production project) is that SOA project has ESB (like Mule ESB, Camel or other) which intended to route messages (SOAP, JSON etc) from one service to another, and acts like a mediation layer between services. Services in turn, does not know about each other and just send\receive messages from ESB.
In opposite to SOA, microservice architecture implies that services will communicate with each other directly, using some protocol (usually HTTP).
Microservices similar to SOA in that we focus on business functionality and separate it into single, small deployable chunk.
I am working on a monolith system. All of it's code is in one repository (Web API and background workers). System is written in Nodejs and MongoDB (Mongoose) is used as a data store. My goal is to set a new path how project should evolve. At first I was wondering if I could move towards microservices based architecture.
Monolith architecture creates some problems:
If my background workers needs to scale. I have to deploy all the project to the server despite only using a small fraction of it.
All system must be redeployed when code changes. What if payment processor calls webhook while system is being redeployed?
Using microsevices advantages are quite obvious:
Smaller code base for individual microservice. Easier to reason about it.
Ability to select programming tools best for particular use case.
Easier to scale.
Looking at the current code I noticed that Mongoose ODM (Object Document Mapper) models are used across all the project to create, query and update models in database. As a principle of a good programming all such interactions with database should be abstracted. Business logic should not leak into other system layers. I could do that by introducing REPOSITORY pattern (Domain Driven Design). While code is still being shared across web api and it's background workers it is not a hard task to do.
If i decide to extract repositories into standalone microservices than all bunch of problems arise:
Some sort of query language must be introduced to accommodate complex search queries.
Interface must provide a way to iterate over search results (cursor based navigation) without returning all database documents over network.
Since project is in it's early stage and I am the only developer, going to microservices based architecture seems like an overkill. Maybe there are other approaches I should consider?
Extracting business logic and interaction with database into separate repository and sharing among services to avoid complex communication protocols between services?
Based on my experience with working in Microservices for last few years, it seems like an overkill in current scenario but pays off in long-term.
Based on the information stated above, my thoughts are:
Code Structure - Microservices Architecture (MSA) applying in above context means not separating DAO, Business Logic etc. rather is more on the designing system as per business functions. For example, if it is an eCommerce application, then you can shipping, cart, search as separate services, which can further be divided into smaller services. Read it more about domain-driven design here.
Deployment Unit - Keeping microservices apps as an independent deployment unit is a key principle. Hence, keep a vertical slice of the application and package them as Docker Image with Application Code, App Server (if any), Database and OS (Linux etc.)
Communication - With MSA, communication between services become a key and hence general practice is to remain with the message-oriented approach for communication (read about the reactive system and reactive programming for more insight).
PaaS Solution - There are multiple PaaS solutions available, which you can apply so that you don't need to worry about all the other aspects like container management, container orchestration, auto-scaling, configuration management, log management and monitoring etc. See following PaaS solutions:
https://www.nanoscale.io/ by TIBCO
https://fabric8.io/ - by RedHat
https://openshift.io - by RedHat
Cloud Vendor Platforms - AWS, Azure & Google Cloud all of them have specific support for Microservices App from the deployment perspective, which we can use as an alternative solution if you don't want to deploy PaaS solution in your organization.
Hope these pointers will have in understanding the overall landscape so that you can structure your architecture for future need.
I am working on a monolith system... My goal is to set a new path how project should evolve. At first I was wondering if I could move towards microservices based architecture.
In what ways do you need to evolve the project? Will it be mostly bugfixes, adding features, improving performance and/or scalability? Do you anticipate other developers collaborating in the future? Are you currently having maintenance issues? The answers to these questions (and many more) should be considered in guiding your choices.
You seem to be doing your homework around the pros and cons of a microservice architecture, so if you haven't asked yourself why you're even doing this in the first place, now would be good time to do so.
Maybe there are other approaches I should consider?
There's always the good old don't-break-what's-going ;)
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 6 years ago.
Improve this question
There are a lot of IoT platform in the market like AWS Amazon IoT and Microsoft Azure Hub, I understand all the features that are offered by those platforms.
Questions:
Couldn't I implement all those features on a normal web application which can handle communication and all these features and run this application on a cluster of unmanaged server and have the same result?
When shall I use a normal web application and when shall I use IoT platform?
Of course you can implement your own IoT hub on any web application and cloud (or on-prem) platform, there is nothing secret or proprietary in those solutions. The question is, do you want to do that? What they offer is a lot of built in functionality that would take you some serious time to get production ready when building it yourself.
So:
1) yes, you can build it. Let's compare it to Azure IoT hub and look at what that contains:
a) reliable messages to and from hub
b) periodic health pulses
c) connected device inventory and device provisioning
d) support for multiple protocols (eg HTTP, AMQP, MQTT...)
e) access control and security using tokens
.... and more. Not supposed to be a full feature list here, just to illustrate that these solutions contains a whole lot of functionality, which you may (or may not) need when building your own IoT solution.
2) when does it make sense to build this yourself? I would say when you have a solution where you don't really neeed all of that functionality or can easily build or setup those parts you need yourself. Building all of that functionality doesn't, generally speaking, make sense, unless you are building your own IoT platform.
Another aspect is the ability to scale and offer a solution for multiple geographic locations. A web application on a cloud provider could easily be setup to both autoscale and cover multiple regions, but it is still something you would have to setup and manage yourself. It would likely also be more expensive to provide the same performance as the platform services does, they are built for millions of devices across a large number of customers, their solution will likely look different under the hood.
Third is time-to-market, by going with a platform service will get you up and running with your IoT solution fairly quick as opposed to building it yourself.
Figure out what requirements you want to support, how you want to scale, how many devices and so on. Then you can do a simple comparison of price and also what it would cost you to build the features you need.
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 6 years ago.
Improve this question
My client ask me to build a realtime application that could chat, send images and videos all in realtime. He asked me to come up with my own technology stack, so I did a lot of research and found out that the easiest one to build would be using below tech stack
1) Node.js and cluster to max out the CPU core for one instance of server - Language
2) Socket.io - realtime framework
3) Redis - pub/sub for multiple instances of server
4) Nginx - to reverse proxy and load balance multiple servers
5) Amazon EC2 - to run the server
6) Amazon S3 and CloudFront - to save the images/videos and to deliver
Correct me if I'm wrong for the above stack. My real question is, can the above tech stack scale 1,000,000 messages per seconds (text, images, videos)?
Anyone who have experienced with node.js and socket.io, could give me an insights or an alternatives of the above stack.
Regards,
SinusGob
My real question is, can the above tech stack scale 1,000,000 messages
per seconds (text, images, videos)?
Sure it can. With the right design and enough hardware. The question your client should be asking is really not whether it can be made to go that big, but at what cost and practicality can it be done and are those the best choices.
Let's look at each piece you've mentioned:
node.js - For an I/O centric app, it's an excellent choice for high scale and it can scale by deploying many CPUs in a cluster (both multi-process per server and multi-server). How practical this type of scale is depends a lot on what kind of shared data all these server processes need access to. Usually, the data store ultimately ends up being the harder bottleneck in scaling because it's easy to throw more servers at the request processing. It's not so easy to throw more hardware at a centralized data store. There are ways to do that, but it depends a lot on the demands of the app for how you do it and how hard it is.
socket.io - If you need efficient server push of smallish messages, then socket.io is probably the best way to go because it's the most efficient at push to the client. It is not great at all types of transport though. For example, I wouldn't be moving large images or video around through socket.io as there are more purpose built ways to do that. So, the use of socket.io depends a lot on what exactly the app wants to use it for. If you wanted to push a video to a client, you could also push just an URL and have the client turn around and request the video via a regular http URL using well known high scale technology.
Redis - Again, great for some things, not great at everything. So, it really depends upon what you're trying to do. What I explained earlier is that the design of your data store and the number of transactions through it is probably where your real scale problems lie. If I were starting this job, I'd start with an understanding of the data storage needs for a server, transactions per second of various types, caching strategy, redundancy, fail-over, data persistence, etc... and design the high scale access to data first. I wouldn't be entirely sure redis was the preferred choice. I'd probably suggest you need a high scale database guy as a consultant early in the project.
Nginx - Lots of high scale sites using nginx so it's certainly a good tool. Whether it's exactly the right tool for you depends upon your design. I'd probably work on this part last because it seems less central to the design and once the rest of the system is laid out, you can then consider what you need here.
Amazon EC2 - One of several possible choices. These choices are hard to compare directly in an apples to apples comparison. Large scale systems have been built out of EC2 so there is proof of concept there and the general architecture seems an appropriate match. If you wanted to know where the real gremlins are there, you'd need a consultant that had done high scale stuff on EC2.
Amazon S3 - I personally know some very high storage and bandwidth sites using S3 for both video and images. It works for that.
So ... these are generally likely good tools to use if they are used in the right way. Redis would be a question-mark depending upon the storage needs of the actual application (you've provided zero requirements and a database can't be selected with zero requirements). A more reasoned answer would be based on putting together a high level set of requirements that analyze what the system needs to be able to do to serve 1,000,000 whatever. Those requirements could be compared with known capabilities for some of these pieces to start a ballpark on scaling a system. Then, you'd have to put together some benchmarking tests to run some tests on certain pieces of the system. As much of the success of failure would depend upon how the app was built and how the tools were used as it would which tools were selected. You can likely make a successful scale with many different types of tools. Heck, Facebook runs on PHP (well, a highly modified, customized PHP that is not really typical PHP at all at runtime).