I about to embark on a new project in my company. I work in an enterprise that is highly governed by standards and best practices. We have Kofax TotalAgility already deployed. I'm trying to use Elsa as a lightweight alternative to Kofax which is built on .Net 4.6. I'm on Blazor Server-Side and .Net 5.
So Elsa has an appeal. Secondly, there s a severe lack of help when it comes to Elsa. A generic or hobbyist developer will not use a Workflow based business layer. Workflows are more common in enterprise environments. We have a load balanced deployment model for apps with AlwaysOn SQL Servers. If I include Elsa embedded in an application having it's tables as a part of the apps DB, I need to deploy it to two nodes pointing to same DB. This creates race conditions when it comes to pick up activities saved in DB and perform action. That is why Kofax is deployed as a single node specially. Which means I need to deploy Elsa based generic solution for all my apps. And I simply do not have a sample or a guide to do this.
Can someone help me understand this scenario: An Elsa deployed and running on a server with IIS exposing it API interface (if it has else deployed embedded in a .Net 5 Web API). A separate application(s) will be, then, leveraging this instance of Elsa.
I may be wrong in my understanding here. Please help.
Elsa 1 (the current release) is not suitable to use on more than a single node. Not only will you encounter concurrency issues as the OP mentions, but workflows with time-based activities will cause a given workflow to execute on every node, which is undesirable in normal use cases.
Elsa 2 (currently available as preview packages on MyGet) is a different story. Like Elsa 1, it is designed for use in your own application as a light-weight solution to add workflowing capabilities. But unlike Elsa 1, it is also designed to run as a separate workflow server, exposing APIs for other applications to interact with. For example, the dashboard application does not access the Elsa database directly, but instead takes advantage of the workflow server's API endpoints. Additionally, Elsa 2 is designed to be hosted on both single node and multi node environments, allowing you to easily scale out the workflow server horizontally.
Elsa 2 is slated to be released end of March.
Related
In Google's latest docs, they say to test Go 1.12+ apps locally, one should just go build.
However, this doesn't take into account all the routing etc that would happen in the app engine utilizing the app.yaml config file.
I see that the dev_appserver.py is still included in the sdk. But it doesn't seem to work in Windows 10.
How does one test their Go App Engine App locally with the app.yaml. ie: as an actual emulated app engine app.
Thank you!
On one hand, if your application consists of just the default service I would recommend to follow #cerise-limón comment suggestion. In general, it is recommended for the routing logic of the application to be handled within the code. Although I'm not a Go programmer, for single service applications that use static_files and static_dir there shouldn't be any problems when testing the application locally. You might also deploy the new version without promoting traffic to it in order to test it as explained here.
On the other hand, if your application is distributed across multiple services and the routing is managed through the dispatch.yaml configuration file you might follow two approaches:
Test each service locally one by one. This could be the way to go if each service has a single responsibility/functionality that could be tested in isolation from the other services. In fact, with this kind of architecture the testing procedure would be more or less the same as for single service applications.
Run all services locally at once and build your own routing layer. This option would allow to test applications where services needs to reach one another in order to fulfill the requests made to them.
Another approach that is widely used is to have a separate project for development purposes where you could just deploy the application and observe it's behavior in the App Engine environment. As for applications with highly coupled services it would be the easiest option. But it largely depends on your budget.
Say I have a front end node and three backed nodes tools, blog, and store. Each node communicates with the other. Each of these nodes have their own set of languages and libraries, and have their own Dockerfile.
I understand the DevOps lifecycle of a single monolithic web application, but cannot workout how a DevOps pipeline would work for microservices.
Would each micro-service get its own github repo and CI/CD pipeline?
How do I keep the versions in sync? Let's say the tools microservice uses blog version 2.3. But blog just got pushed to version 2.4, which is incompatible with tools. How do I keep the staging and production environments in sync onto which version they are supposed to rely on?
If I'm deploying the service tools to multiple different servers, whose IP's may change, how do the other services find the nearest location of this service?
For a monolithic application, I can run one command and simply navigate to a site to interact with my code. What are good practices for developing locally with several different services?
Where can I go to learn more?
Would each micro-service get its own github repo and CI/CD pipeline?
From my experience you can do both. I saw some teams putting multiple micro-services in one Repository.
We where putting each micro-service in a separate repository as the Jenkins pipeline was build in a generic
way to build them that way. This included having some configuration files in specific directories like
"/Scripts/microserviceConf.json"
This was helping us in some cases. In general you should also consider the Cost as GitHub has a pricing model
which does take into account how many private repositories you have.
How do I keep the versions in sync? Let's say the tools micro-service uses blog version 2.3. But blog just got pushed to version 2.4, which
is incompatible with tools. How do I keep the staging and production
environments in sync onto which version they are supposed to rely on?
You need to be backwards compatible. Means if your blogs 2.4 version is not compatible with tools version 2.3 you will have high dependency
and coupling which is going again one of the key benefits of micro-services. There are many ways how you get around this.
You can introduce a versioning system to your micro-services. If you have a braking change to lets say an api you need to support
the old version for some time still and create a new v2 of the new api. Like POST "blogs/api/blog" would then have a new api
POST "blogs/api/v2/blog" which would have the new features and tools micro-service will have some brige time in which you support
bot api's so it can migrate to v2.
Also take a look at Semantic versioning here.
If I'm deploying the service tools to multiple different servers, whose IP's may change, how do the other services find the nearest
location of this service?
I am not quite sure what you mean here. But this goes in the direction of micro-service orchestration. Usually your Cloud provider specific
service has tools to deal with this. You can take a look at AWS ECS and/or AWS EKS Kubernetes service and how they do it.
For a monolithic application, I can run one command and simply navigate to a site to interact with my code. What are good practices
for developing locally with several different services?
I would suggest to use docker and docker-compose to create your development setup. You would create a local development network of docker
containers which would represent your whole system. This would include: your micro-services, infrastructure(database, cache, helpers) and others. You can read about it more in this answer here. It is described in the section "Considering the Development Setup".
Where can I go to learn more?
There are multiple sources for learning this. Some are:
https://microservices.io/
https://www.datamation.com/applications/devops-and-microservices.html
https://www.mindtree.com/blog/look-devops-microservices
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/multi-container-applications-docker-compose
I came a cross this boilerplate just couple of weeks ago and it's the coincidence that I was working on designing Multi-tenant Saas Architecture using .Net Core Framework, EFCore as ORM, SPA(Angular)as presentation layer, and OData Api but then I found this boilerplate is exactly what I am looking for. I have one question how to set-up configuration on this sample Event Saas app to make it as Single Deployment with multi-database?
I have noted there is appsetting.json where subdomains are stored and in each entity for example Event is inherited from IMustHaveTenant that means each entity should have TenantId means this setup is suitable for single deployment with single database (database filter is automatically applied by aspboilerplate) but I am looking to make it single deployment with multiple database (Each database per tenant). It will be great if you just give me some clues.
Note: This is what I am talking about.
Thank you.
I am new in Service Now platform, developing a custom app using the service portal and I am looking for some architectural advice from experts.
My storyline is my service is gonna serve different companies as per their requirements by easy codebase maintenance. for example, I am having a base app which has some concrete requirements that fit for all companies, but there will be some other features for company specific, like feature A for company A, feature B for company B and so on. So my initial plan was like classic software development that is to have a single codebase using git that will have multiple feature branches that will deploy to multiple instances. But sometimes some situation where I might need to merge the branches that is not possible now. My question here is there any alternative way to do that? Other possible scenarios here is should I go with a single instance with ACL based data separation? (but that not feels scalable to me cause the amount of the data will be huge after some time) or is that possible to apply regular SAAS architecture like multitenancy(single app with multiple databases) with some configuration wise feature separation?
Thanks in Advance.
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.