What is the recommended process flow for Development regarding development and as a CMS user?
A three tier architecture seems secure: 1)Quality Assurance 2)Production 3)Live
However would a 2 Tier: Production into Live straight away be okay to use, What are peoples thoughts on this? Is the three tier a general practice?
Thank You, Aisling
Related
How a saas application coding is different from our traditional web applications? Please share some link where I can find some helpful tutorials. Thanks in advance for your time and help.
The main differences between the code of SaaS applications and traditional applications is the concurrency control and the resources consumption.
The concurrency control is necessary when you have multiple users accessing the same resources, so things like thread safety are crucial to this kind of application.
About the resources consumption, the efficiency of SaaS applications are much more important than traditional applications, because the hosting costs of SaaS are (normally) paid by the company who own the app, and impact directly on the company finance. Plus, all the resources used are multiplied by the number of users.
Other main concern that should be considered when programming SaaS applications is about the data separation: a user should never, ever, see data of another users registered in the application (there are exceptions, of course). This have extra weight when talking about SaaS applications in areas like finance and fiscal management, etc.
If you have more questions or want me to expand the answer in some specific direction, please let me know in the comments section.
I have a business idea which I want to materialize for sometime .. I recently shared my idea with 2 close friends who also found it very interesting, new and doable plus the cost included for the project to start is reasonable and they have planned to invest in it. Much of the success of this project app depends on the proper marketing element out of which most of the time, you have to personally meet up with clients/vendor and make them use your application.
The idea is to connect local ecommerce (retail shops, businesses, vendors, etc.) with users/customers through a messaging app mostly similar to whatsapp. I have already started to look for a xmpp/jabber developer who can accomplish our requirements. We are expecting him to develop the app and also set-up the server requirements. Our budget lies within $3000-4000 range for the project to initiate.
I want the app to have the following aspects:
a) user friendly GUI
b) highly scalable (planning to start within my city located in south asia)
c) location sharing (want users to navigate nearby shops/vendor offering their type of goods/services)
d) have a user review feedback against vendors and an additional page for vendor profile/rating system
e) only customer - vendor chats with functionalities like camera snaps, audio recording (just like whatsapp).
f) both for ios and android
Now the whole idea outlaid, after reading lots of articles, discussion and tutorials, I have some questions (I am a non-technical person btw):
1- I believe ejabberd is the best option as compared to tigase or prosody due to high scability. Is this ok to go with or should I look at other xmpp servers?
2- Currently, I am planning to launch this application within my city (rated as worldwide no.2 as per population stats of above 25m people), should I set-up a local server with high internet bandwith and a powerful machine or should I outsource it to some xmpp hosted server in the US (as their technological infrastructure has always provided quality service).
3- Should I be worried about the developer stealing the source code or is there any effective way to minimize this risk?
4- Any ideas what other things I am missing. This is dead serious for me and I am willing to do anything to get this project on the road.
(P.S.: The idea for this app is similar to the existing app called Lookup but I am planning to add some variations to it)
Thanks and sorry for being a bit lengthy ..
Regards,
Ahmed
ejabberd is indeed likely your best bet. However, be careful about the budget. To launch a quality service in an highly competitive area you have to have a significant budget, both development and marketing, if you expect your project to succeed.
We have built an enterprise web application on asp.net platform which is well load balanced across several servers. We are struggling a bit in terms of doing regular deployments as the application has been defined with an SLA of zero downtime.
Any guidance / tips would be highly appreciated for Implementing best practices to support uninterrupted deployment.
My two favorite books that cover some of these topics are Continuous Delivery by Humble/Farley and Web Operations by Allspaw/Robbins.
I think the "easy" part here is to do a rolling deployment where you pull a node out of the load balancer, upgrade it, run smoke tests, and place it back in the load balancer. Different users will encounter different versions of the app, but you get zero downtime.
The hard part is the backend system / database that these web-apps are likely hitting. You basically need to have both old and new schemas available concurrently which is challenging. Look at techniques like the expand / contract database pattern as an approach to pulling this off.
Related question: What is the most efficient way to break up a centralised database?
I'm going to try and make this question fairly general so it will benefit others.
About 3 years ago, I implemented an integrated CRM and website. Because I wanted to impress the customer, I implemented the cheapest architecture I could think of, which was to host the central database and website on the web server. I created a desktop application which communicates with the web server via a web service (this application runs from their main office).
In hindsight this was rather foolish, as now that the company has grown, their internet connection becomes slower and slower each month. Now, because of the speed issues, the desktop software times out on a regular basis, the customer is left with 3 options:
Purchase a faster internet connection.
Move the database (and website) to an in-house server.
Re-design the architecture so that the CRM and web databases are separate.
The first option is the "easiest", but certainly not the cheapest long term. Second option; if we move the website to in-house hosting, the client has to combat issues like overloaded/poor/offline internet connection, loss of power, etc. And the final option; the client is loathed to pay a whole whack of cash for me to re-design and re-code the architecture, and I can't afford to do this for free (I need to eat).
Is there any way to recover from when you've screwed up the design of a distributed system so bad, that none of the options work? Or is it a case of cutting your losses and just learning from the mistake? I feel terrible that there's no quick fix for this problem.
You didn't screw up. The customer wanted the cheapest option, you gave it to them, this is the cost that they put off. I hope you haven't assumed blame with your customer. If they're blaming you, it's a classic case of them paying for a Chevy while wanting a Mercedes.
Pursuant to that:
Your customer needs to make a business decision about what to do. Your job is to explain to them the consequences of each of the choices in as honest and professional a way as possible and leave the choice up to them.
Just remember, you didn't screw up! You provided for them a solution that served their needs for years, and they were happy with it until they exceeded the system's design basis. If they don't want to have to maintain the system's scalability again three years from now, they're going to have to be willing to pay for it now. Software isn't magic.
I wouldn't call it a screw up unless:
It was known how much traffic or performance requirements would grow. And
You deliberately designed the system to under-perform. And
You deliberately designed the system to be rigid and non adaptable to change.
A screw up would have been to over-engineer a highly complex system costing more than what the scale at the time demanded.
In fact it is good practice to only invest as much as can currently be leveraged by the business, using growth to fund further investment in scalability, should it be required. It is simple risk management.
Surely as the business has grown over time, presumably with the help of your software, they have also set aside something for the next level up. They should be thanking you for helping grow their business beyond expectations, and throwing money at you so you can help them carry through to the next level of growth.
All of those three options could be good. Which one is the best depends on cost benefits analysis, ROI etc. It is partially a technical decision but mostly a business one.
Congratulations on helping build a growing business up til now, and on to the future.
Are you sure that the cause of the timeouts is the internet connection, and not some performance issues in the web service / CRM system? By timeout I'm going to assume you mean something like ~30 seconds, in which case:
Either the internet connection is to blame and so you would see these sorts of timeouts to other websites (e.g. google), which is clearly unacceptable and so sorting the internet is your only real option.
Or the timeout is caused either by the desktop application, the web serice, or due to exessively large amounts of information being passed backwards and forwards, in which case you should either address the performance issue how you might any other bug, or look into ways of optimising the Desktop application so that less information is passed backwards and forwards.
In sort: the architecture that you currently have seems (fundamentally) fine to me, on the basis that (performance problems aside) access for the company to the CRM system should be comparable to accesss for the public to the system - as long as your customers have reasonable response times, so should the company.
Install a copy of the database on the local network. Then let the client software communicate with the local copy and let the database software do the synchronization between the local database server and the database on the webserver. It depends on which database you use, but some of them have tools to make that work. In MSSQL it is called replication.
First things first how much of the code do you really have to throw away? What language did you use for the Desktop client? Something .NET and you may be able to salvage a good chuck of the logic of the system and only need to redo the UI and some of the connections.
My thoughts are that 1 and 2 are out of the question, while 1 might be a good idea it doesn't solve the real problem. And we as engineers should try and build solutions not dependent on the client when ever possible. And 2 makes them get into something they aren't experts at and it is better to keep the hosting else where.
Also since you mention a web service is all you are really losing the UI? You can alway reuse the webservices for the web server interface.
Lastly you could look at using a framework to help provide a simple web based CRUD to start and then expand from there.
Are you sure the connection is saturated? You could be hitting all sorts of network, I/O and database problems... Unless you've already done so, use wireshark to analyze the traffic; measure the throughput and share the results with us.
What is the most typical structure of business where you want to develop several web services? Should one establish a company for each of them or keep under one? I would like to hear your experiences maintaining such situation, keeping in mind the global focus.
By far the two most critical sets of issues determining the answer to this question are legal and financial (including, but not mainly, accounting). So it's hard to see how this question fits with the intent of this site.
It is advised to provide more background information on the topic. Business plans for SaaS companies can range from large cloud computing service vendors (with integrated solutions) and up to business analytics providers targeting specific market niche.
Business is a bit like programming: Keep It Simple (Stupid). Do not create multiple companies, unless there is a good reason to do it.
If You Planning to use python, you can use Django to build saas application,
this video Build SaaS application in Python django will explain about getting started with Sass.
Thanks