with the cloudfoundary landscape on sap cloud platform , i was looking at approach / best practise when multiple developers work on the same app.
Should each developer have a seperate space and must push the app each time they want test ?
or
Should there be one "devopment" space with multiple apps and some kind of service sharing among the different apps that each developer will push ? . In this approch i do see the issues if i change a service (eg db) that might effect other apps that share it.
I went through the documentation but did not get any hints about multiple developers working in the space , so any advice / experiences is highly appreciated
I don't think anyone can tell you what makes sense for your organization. You need to think about how you want to organize your users, applications & spaces. Quota management plays into this, but so does access to apps & services.
Things to consider:
Who needs access to the apps you're putting into the space? You can control this with the space roles (space dev, manager & auditor).
How to you want to manage the spaces? This is going to give you some insight into how you want to structure your orgs. Org permissions allow an operator to delegate management to someone else (org manager, auditor roles).
How do you need to be able to restrict the resources that your uses consume? i.e. quotas. You can apply quotas to orgs & spaces. Consider how you want to restrict what groups can do.
Consider org/space boundaries. Will you have need to share things like services across orgs & spaces? There is some capacity to do this through the foundation, but be careful because individual service brokers need to support this also. At the time of writing some do and some do not. Those that do not would need to be shared with the must less convenient user provided service.
https://docs.cloudfoundry.org/devguide/services/sharing-instances.html
Consider if you need to do billing or charge-back. Doing this per org/space makes sense, so you would need to align that with how you're doing billing/charge-back.
I wouldn't suggest adopting one of these strategies without thinking it through first, but here are a couple examples of what I've seen people do.
In teams where the developers manage throughout the full cycle, I've seen orgs be used to group development teams and spaces use to group project or apps. Thus team A has access to org A, which has spaces X, Y and Z for App X, Y and Z. App X, Y and Z deploy dev, test, qa and prod into the same space.
In companies with more traditional structures where dev teams pass off code to an ops team, I typically see orgs and spaces to facilitate that separation. Devs have their own orgs & spaces for development & testing. Ops has their own orgs and spaces for production. The two do not mix.
There are also variations on this, so again think through what makes sense for you and your company.
Hope that helps!
The spaces on Cloud Foundry have the functional purpose of providing quota management and control management to a group of people. As such, you should structure the spaces, depending on your need to isolate/control applications.
The most common use case for spaces are:
- dev / qua / prod
- department_a / deparment_b;..
Regarding the development of shared services, please make sure you understand about CF services, they provided different mechanism from regular apps, for example, a service instance (like a DB), can be shared between different applications on different spaces:
https://docs.cloudfoundry.org/devguide/services/sharing-instances.html
Related
i just arrived on this architecture, am doing a lot of research and i understood how it work in general but it's all theorical.
I decided to separate each step for the development of this architecture to start implementing so i can understand better these steps.
The first that i wanted to learn was the tenant provisioning, i wanted to apply it on AWS to mirror a production software example.
So, starting on that the common AWS service that i see most people using is AWS Cognito, but it's not clear in my mind the steps of the implementation, like how should i get the tenant data to onboard him in my app? Assuming it's tier based.
Should i have one database to store all tenants data separate from the application database?
I want to use microservices on this one because i think is better to onboard the tenant with different tiers and much more benefits.
Which AWS services should i use to make this process work? I'm not really asking about the implementation itself but a path to understand which services to use and how it connects with each other.
I hope i was clear about my doubts, english is not my mother tongue, sorry about that!
You are thinking in the right direction. However, there are decisions you need to make before diving into any saas service stack. I would start with
Planning my infrastructure - how many tenants/group.
the kind of tenant onboarding system you want
How will tenants onboard their users and manage authorization/authentication
Multitenant architecture, which needs to account for several things at the least like - DB model, shared vs isolated, data privacy, design keeping in mind industry data security standards
what will be your tenant deployment model. Remember one of the disadvantages of multitenancy is also slow time to market.
Your API stack needs to account for which apis needs to be multitenant and which are generic product offerings.
operational tool to monitor app health, client analytics.
how will you meter and bill the client and other non-functional decisions.
AWS offers good documentation to get started here : https://aws.amazon.com/blogs/apn/building-a-multi-tenant-saas-solution-using-aws-serverless-services/
I am new to micro services and I am keen to use this architecture. I am interested to know what architecture structure should be used for systems with multiple customer interfaces where customer systems may use one or many of the available services. Here is a simple illustration of a couple of ways I think it would be used:
An example of this type of system could be:
Company with multiple staff using system for quotes of products
using products, quotes and users mirco services
Company with website to display products
using products micro service
Company with multiple staff using system for own quotes
using quotes and users micro services
Each of these companies would have their own custom build interface only displaying relevant services.
As in the illustrations all quotes, products and users could be stored local to the mirco services, using unique references to identify records for each company. I dont know if this is advisable as it could make data difficult to manage and could grow fast making it difficult to manage.
Alternatively I could store such as users and quotes local to the client system and reference the micro services for data thats generic. Here mirco services could be used just to handle common logic and return results. This does feel someone illogical and problematic to me.
I've not been able to find anything online to explain the best course of action for this scenario and would be grateful for any experienced feedback on this.
I am afraid you will not find many useful recipes or patterns for microservice architectures yet. I think that the relative quiet on your question is that it doesn’t have enough detail for anybody to readily grasp. I will make a wag:
From first principles, you have the concept of a quote which would have to interrogate the product to get a price and other details. It might need to access users to produce commission information, and customers for things like discounts and lead times. Similar concepts may be used in different applications; for example inventory, catalog, ordering [ slightly different from quote ].
The idea in microservices is to reduce the overlap between these concepts by dispatching the common operations as their own (micro) services, and constructing the aggregate services in terms of them. Just because something exists as a service does not mean it has to be publicly available. It can be private to just these services.
When you have strained your system into these single function services, the resulting system will communicate more, but will be able to be deployed more flexibly. For example, more resources &| redundancy might be applied to the product service if it is overtaxed by requests from many services. In the end, infrastructure like service mesh help to isolate the implementation of these micro services from the sorts of deployment considerations.
Don’t be misled into thinking there is a free lunch. Micro service architectures require more upfront work in defining the service boundaries. A failure in this critical area can yield much worse problems than a poorly scaled monolithic app. Even when you have defined your services well, you might find they rely upon external services that are not as well considered. The only solace there is that it is much easier to insulate your self from these if you have already insulated the rest of your system from its parts.
After much research following various courses online, video tutorials and some documentation provided by Netflix, I have come to understand the first structure in the diagram in the best solution.
Each service should be able to effectively function independently, with the exception of referencing other services for additional information. Each service should in effect be able to be picked up and put into another system without any need to be aware of anything beyond the API layer of the architecture.
I hope this is of some use to someone trying to get to grips with this architecture.
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
Trying to understand why it's a good idea for a distributed dev team to work in "one" common CF org and space... and what the downside is of not sharing the same space.
After talking to several folks quite knowledgeable of CF, my conclusion is that it's a good idea to share the space for the following two reasons:
1. if there is a high inter-dependency across individually developed / deployed services, .. and / or ...
2. is there is a fee for each service instance, and hence you would want to limit the number of service instances per project
In all other scenarios, it does not really matter. Developers can collaborate on GitHub, and do pushes within their own individual spaces.
Did I get that right?
I think I can explain the base idea of spaces in cloud foundry. ( I don't sure what is your project and if it'll fit you)
If you don't use a cloud, usually you will have 3 servers (minimum):dev,stage, and prod. (again on some type of projects you don't need it)
The dev space is for the developers (let's say you creating a website, one of your developers finished a page in the site he\she uploads it to dev space).
You and your devs can see the status of the deployment in this space
once you think dev is stable enough (or end of the sprint if you in agile methodology) you move dev space to staging
in staging usually QA looking for defect and make sure everything works (any bug found in here is opened on the dev team which fixing it on dev and so on)
once staging is tested you move it to prod
cloud foundry supports this mechanism using spaces
org is for different projects
all I said here isn't enforced in any way by cloud foundry eventually you can choose the best way that working for you
Could someone please direct me to some good documentation or feedback here on what are best practices for implementing web services in an application that handles different concerns? For example, should I create different services, one that handles security, (AuthService), one that handles data-entry for customer service reps, (CRUDService), BillingService and so on or should I just encapsulate all these "services" into one, e.g. ApplicationService? Basically, I am asking if it is bad design to create multiple services (files) within one application. Can some of you note on your experiences or what you've experienced?
Also, let's say three of the listed services from above connect to the same database, but are actually hitting totally different concerns, e.g. one is for all transactions like CRUD, and the other one is for purely reporting purposes. Should I create two services here, one CRUDService and the other for ReportingService? Is it bad to create two different database connections via these 2 services? Or how can I share the same database connection with different services?
I think there is a tendency among publicly available services to just dump everything into one service. Which, may not be a bad idea for a publicly available API. It just makes it easier for developers. However, for any project i work on, i try to break things down into logical groups. This way your client doesn't need to be inheriting functionality it may not need. Updating services would also be a slightly easier task because you're only affecting a certain subset of your web service framework and not everything. So if your service contract breaks and your clients no longer support it, they may still be able to use other parts of your system, but not that particular one. Where as if you break a contract on your aggregated service, everything fails. Finally, if you have to implement something like a fail-over support, you have more flexibility to choose which service requires more fail-over nodes, allowing you to better manage your resources allocation.
If you want best practices take a look to the SOA Design Pattern Catalog