Kinvey is Backend as a Service | Mobile Cloud Backend as a Service
Is Kinvey ( http://www.kinvey.com/ ) good, or using custom Java server with database a good idea ?
I am a member of the Kinvey engineering team, and can talk a bit about BaaS in general. While creating your own backend gives you a lot of flexibility and control, it is also a lot of work.
Back-end as a service providers like Kinvey offer a platform to speed up app development and have already done a lot of the work for you. Tasks like managing a database server and a web service front-end, managing the storage and streaming of files, providing a cross-platform push notification, providing a centralized user and authentication store, integration with social networks, buisiness logic and more are easily implemented with SDKs for each platform.
If I were to list the three main advantages of BaaS, they are:
Ease of implementation
Ready-made back-end platform for cross-platform apps
Automatic scalability if your app becomes successful
As far as disadvantages, your backend feature set becomes dependent on the vendor, and you certainly get more flexibility with a custom solution, but that can often be overcome with business logic. In my own (admittedly biased) opinion, the flexibility and cost savings make it worth at least giving BaaS a try seeing if the feature sets meet your specific needs.
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 have a SaaS based multi-tenant monolith application (built with Django), that I want to divide into microservices based architecture. But I am not sure how to divide the application into correct partitions. And on what aspects should I take care of?
In case of monolith application, it's easy to understand that I have a tenant model that decides the schemas but how this will be done in microservices if I want each service to be multi-tenant? Or should I even make the services multi-tenant?
If you're already using OAuth and/or generating JWTs for user authentication/authorization, I'd recommend any new services that need tenant scoping to require a user access token be provided in requests just like your Django app. This lets you standardize how credentials and tenant scoping is expected to be passed, and verifying JWTs is a pretty easy process to implement.
That being said, it's also important to point out that you shouldn't require that services use access tokens or have any kind of tenant scoping at all. Not only is it possible that specific services don't require tenant scoping, but it's also possible that they might want to define a tenant differently from the main Django app (e.g. a simple tenant_id). For example, a payments service that only accepts a dollar amount and a credit card doesn't care what the tenant is and would be perfectly safe to call from the main Django application (of course you should prevent public access to the service too).
The best way to think about how new services should be designed is in a vacuum - without care for how other services are designed or how they store their data. Your service was built to perform a task and it defines for itself what parameters it needs to perform that task, how it executes that task, and how it stores the data it needs for future tasks. This independence from the design of other microservices in the stack is part of the power of designing service-oriented systems. It allows creators to pick the right tools for the job, and allows them to create meaningful features without needing to collaborate with dozens of team members that they often don't know.
Hope this helps, and good luck.
From what I know, Parse offers convenient communication stacks for various platforms such as iOS, so it is easy to build clients that use your web app.
But Parse also seems to be tightly integrated with Facebook. If you were to build a web app that does not need Facebook, but that may integrate with Facebook in the long term, is Parse the clear winner over deploying directly to AWS, or are there important disadvantages to consider?
As far as I understand their page Parse is a PaaS (platform as a service) provider like Heroku and others while AWS is a IaaS (infrastructure as a service) provider.
Pros for PaaS:
They care about the infrastructure
You build your app on an existing platform
For the start you don't need "ops-guys" as you don't do ops
You can take their knowledge and prebuilt tools for your advance
Pros for IaaS:
You have full control about the underlaying infrastructure
You can start with a greenfield and build what ever you want
You can use tools like Puppet / Chef / ... to control your servers
You don't have to pay for the additional stuff you get when using PaaS
(but have to pay your people for it)
So there is not a winner of this "battle" but you have to decide whether you want to use prebuilt tooling and give some independence for this or whether you want to have the absolute control over everything (nearly as you can't touch the hardware) and invest time and manpower into building your own tooling.
"Better, Faster, Cheaper.."
If you are pursuing mobile first strategy, Parse is a great tool for bootstrapping a mature, full web-presence from nothing more than an original beta app.
I dont have direct experience with AWS.
I have used Heroku/Parse integrating (very quickly) a stand alone mobile app with the back-end where the back end needs to cover following:
DB/persistence/noSql
Workflow - async tasks
REST API interface HTTP
Once the mobile app existed with only stubbed local data , Parse allowed a single engineer to build out ALL infrastructure mentioned above very quickly, taking the app from single user to multi-user with full DB and workflow that backs client side events with considerable server-side and cloud side business logic and process. Scaling related startup stuff that used to take weeks took only days.
The compression (time&money) when scaling up an app stack is really something. The Parse API did almost everything that i needed with one small exception (remuxing UGC media).
Personally, i abandoned the parse/android SDK in favor of a more robust REST API (threading on client-side and heavy HTTP activity ).
Developers used to Curl/REST dev stacks will take to Parse.
For personal and university research reasons I am thinking of building a simple CRM using a service oriented architecture. Its meaning is just to explain the architecture itself, not commercial use.
I was thinking of implementing a CRM that offers a simple analytics service and customer care (user storing, personal comments, and few other things).
The architecture that I'm designing defines:
- WebGUI (a client of the other services)
- AnalyticsService (a service that receives data, analyzes and collect it)
- CustomerCareService (a service that uses RESTful APIs to apply CRUD operations).
Each service has it own database, being completely independent from others. They expose a public interface. The interface of course must provide some sort of authentication, to deny unautorized requests.
The advantages I'd like to explain in this kind of architecture is the possibility to have all things indepentent and the ability to combine them to offer new services (for example if there was an OrderService to handle orders it would be easy to combine it with Customer using the public APIs). The big advantage to me is that it'd be easy enough to build other clients that use these services.
I don't know what is some good Authentication method, that could be easy to implement, I'm also not sure about how to make this APIs (use XML or plain REST APIs with GET/POST data). I've worked with Amazon, PayPal and other company APIs, they seem to use REST services (paypal uses an ugly _cmd GET parameter while Amazon uses better URI) to know what to do, but reading something about SOAs it appears that people also use XML. Of course I also need to take into account that the web interface must be able to recognize the logged in user, get the permissions (token or whatever else) and use it with services to show information.
So I'm not sure SOA is the kind of architecture I'm really building up... is it SaaS instead of SOA?
I think it would be better to use RESTful applications, with JSON or something like that to implement it (I'm not a big fan of XML, I find it to be too verbose).
For clarity I'm listing here my questions:
Is this kind of architecture called SOA or SaaS (or both)?
What is a good implementation for what I want to obtain? (please explain it as more detailed as possible)
What sort of authentication is more suitable for a client (user token vs OAuth or similiar)
Do you have some suggestion for this kind of project?
I've about 3 months to do it, so I cannot do something real complex (beside the fact that it would not be realistic for a single programmer).
I know Python (WSGI frameworks), Ruby on Rails, C/C++ and other languages (.net excluded) and I'd like to develop it under a Linux environment (MySQL or Postgres, or even a NoSQL if you have any suggestion for the right choice), I could also combine several languages being these services independent programs.
What I'd like here is to have some good point of view and some good suggestion.
Thanks!
I would define SaaS as a Business model rather than an architecture; however like all business domain requirements it will influence systems architecture but it, itself is not. What you have defined is essential a Service Oriented Architecture.
Your statement "independent and the ability to combine them to offer new services" is the essential non-functional design requirement that suggests SOA.
Good implementation for SOA is about having well defined and flexible interfaces, with very clear delineation of responsibilities. However it is difficult subject to be prescriptive about. The proof is in the eating; does it provide that flexible reuse. My suggestion is spend time reading SOA design pattern resources, and understand the defining characteristics with regard to the appropriate context for use. Then apply the Single Responsibility principle appropriate level of abstraction. c.f. (Domain) Space Based Architecture is kind of SOA meta-pattern.
In regard to Authorisation, I recommend following the service approach, use a distribute directory services system like open LDAP, and note that is entirely reasonable for service provides and users to have their own credentials and you can use Public-Private keys for signing messages.
The main suggestion is study and learn from experience of others:
http://www.soapatterns.org/
http://martinfowler.com/eaaCatalog/
SOA doesn't forces to use XML.
Currently web technologies dominate, and define future.
So we in my company selected JSON RESTful services as foundation. And SOA as principles.
There is no sense to suggest languages, because the purpose of SOA and good implementation is
- to enable any language or framework to be used
(FYI we use Java with Spring MVC-based web-services, Node.js, PHP)
Can anyone tell me what the need/advantage is to using a web service with an asp.net gui and using Linq to SQL? The web service layer seems unnecessary. Linq to SQL is completely new to me and I am researching as I am setting up a new project. Does anyone have any experience with this?
You would expose services for those cases in which other applications may need to access your data (such as a smart client, another application, a winforms app, etc.). A lot of people will develop using web services to prevent themselves from having to restructure to web services in the future.
In almost any professional/enterprise web application you want to separate the UI tier from the data access layer so you would not embed Linq to SQL calls in the UI tier. Instead you would have a service tier in between, whether its web services, WCF, or just a DLL with business logic that orchestrates your data access layer. Independent tiers are easier to maintain, update, refactor, and learn so the up front investment in creating them is worth the effort.
It is certainly not necessary, but can be handy in case you want to keep your data access layer on a separate server from your presentation server (ASP.NET). A web service allows you to restrict communication between the two servers to only port 80.
Note that this could apply to plain old ADO.NET or anything else too.
Webservices became a separation layer because they were intended as a platform agnostic way of sending data to other software. They are websites that serve information to other software and not directly to the user.
A webservice is an overhauled separation layer for a website and can not completely replace a good data, business logic and UI separation.
Do it as your logic tells you to, but beware of the performance drops that you pay if you do not need to communicate to other software.
Completely agree with Ovidiu Pacurar. Web services are NOT a good choice for modeling layers of concern. You should do this using good old fashioned OO design. There is no reason for a web application to call web services within itself for data access unless they are intended for client ajax calls or if you need to run the business/data layer on another server for extreme security concerns.
Agreed with previous poster. You'd probably want to do this to apply the "Separation of Concerns" idea...