I am beginning work on an individual project to bring an existing product out of the dark ages of classic ASP and into the light. My biggest decision to make before embarking on this lengthy journey is determining what frameworks and methodology I will implement for the new design.
Right now I am looking at MVC or MVVM (from what I gather this is just Silverlight?) for the web interface, Entity Framework or something I write myself as the model and MSSQL as the data.
Unfortunately I am just a fledgling programmer and I am not particularly aware of trends in the world of programming in general. I don't know what is just a passing fad and what technologies actually have lasting potential. I would really like to use something that is likely to remain relevant for some time. So I am looking to the professionals here for input on ideas that worked for you, pitfalls to watch out for and things to keep an eye on.
I appreciate any and all suggestions, keeping in mind that using the Microsoft and .Net is something of a prerequisite. I really want to make sure I am headed in the right direction before I start as this will probably take several months.
As for frameworks I personally suggest:
ASP.NET MVC 3 of MVC 4, depending on the question if beta software is allowed.
Entity Framework 4.3 or 5.0. 5.0 is a lot faster (is has auto compilation) but it's still a Release Candidate.
AutoMapper to map between Entities and ViewModels.
Ninject for dependency injection (useful if you want to write unit tests).
JQuery for stuff like clientside validation (integrates perfectly with ASP.NET MVC).
Possible some CSS framework like Bootstrap.
Maybe RestSharp so you can easily perform requests.
In case it's a cloud service (most SaaS are) and you'd like to host it on Azure (brilliant integration with the .NET stack) you'll need the Azure SDK.
As for software achitecture:
Use service layers
Use the repository patterns
Use ViewModels to pass to your view instead of entities
Set up a dependency injection container
That's my advice, I personally find this a golden combination for building enterprise applications (while not wasting too much time configuring lots of things).
Pitfalls:
I don't know if unit testing is really necessary. I should definately keep it in mind while setting up the architecture, but I personally choose to do that later because I don't even know if my product will succeed, so I can better put my time in building a fast Minimal Viable Product.
Don't assume anything. You can waste months of your precious time working on a cool feature that you think everyone will like, but often this is not the case. Do just the absolutely required minimum, and improve it later if your users like it.
I will add more to #Leon suggestions as I see those suggestion are great from application framework perspective, while I wanted to write here from cloud methodology perspective.
As you have chosen SaaS, definitely you are moving completely in Cloud while bring your application and data to cloud all together, that's great!!
There are several layers to any cloud application and to understand lets see what a cloud service stack look like. If we take an example of Windows Azure:
You have Compute, where your application runs with a web server (or not).
You have Azure table store which you can use to store key value pair in a row and then access them very fast.
You have Azure Queue allows decoupling of different parts of a cloud application, enabling cloud applications to be easily built with different technologies and easily scale with traffic needs.
You have Access Control Services to authenticate users through OpenID or AD
You have service bus to connect other services in cloud or on-premise at 3rd party.
You have Azure Blob storage to use as web based flat file server
You have Azure Cache (an in-memory cache build to scale in cloud)
You have SQL Azure as you cloud database
There are many more services which you can explorer and use
So when you decide to move your application from traditional web hosting to cloud you really have to look about how to take advantage of these different cloud services to scale your application when needed and save you lots of money.
With you application in Cloud you try something as below:
Keep you application logic as small as possible
Keep your static content outside the compute
Use cloud based cache for fast access as application scale out
Move data out of traditional RDBMS databases to NoSQL Framework (key-value pair, document etc to save money and flexibility), if possible and applicable
Take advantage of other available services to reduce application complexity
If you consider above aspect in your mind you will create a true cloud based application which will be fast and will save you money.
Related
I develop a commercial Asp.Net MVC Web Application. The application is standard, runs on IIS Web Server and utilizes SQL Server database. Our business model is such that we deploy our application on-site in our customers’ Intranet or data center. That is, for each such customer (account) we supply the complete setup, usually installed in a dedicated standalone server. Each such account has its own private content, users, configurations and so on.
We wish to expand and offer our service on the WWW (public Internet). After some research, I’ve chosen Microsoft’s Azure cloud platform to host our application. With some minor efforts (mainly teaching the application to work with Azure’s File Storage using blobs) I’ve managed to fully deploy to the cloud, using three cloud services: Web Site, Data base and File Storage.
Please note that I employ the same code base for the two deployment types (Intranet and Cloud), by using different configurations for Debug, Release – Intranet, Staging – Azure, Production – Azure.
However, the application (as is it written now) can serve only a single customer account, while I need our cloud version to serve numerous accounts (hopefully a lot ;) … each with its own private data set.
Question: which of the following strategies should I employ here?
Change the application so it will support multiple accounts. This means changes both in the data model (adding an Account entity in the data layer, bind it to all content types, etc.) and in the business logic.
Create for each Account its own site on the cloud (web site + data base + file storage services). This means deploying several times the same application to different Azure services.
It’s obvious that the amount of development needed for the 1st approach here is very large as is the risk in stability of the system, while the 2nd approach requires much less effort.
However, im not clear about how to manage a set of many identical services (applications) each serving a different customer account. I’ve started looking for some tools to help me here (e.g. Red Gate), and would love to hear of more.
Another question is the cost – is such a solution, using many cloud services instead of only few, more costly that the more standard “one application for all accounts” approach.
thanx,
I would recommend (1). It is a higher short term cost in terms of development effort, but will be better for two reasons long term:
Cheaper. The costs will go up quite a bit by adding more cloud services. I suppose you could pass this cost on to your client though?
It does become harder to manage releases across many clients.
I would say you can either spend your time refactoring existing code you know - or - you can learn how to do dev ops against Azure to manage releases. Probably easier to refactor what you know instead of learn something new.
As a note there are many great SDKs to automate deployments, scaling cloud services, etc.
Found some good reading about this issue:
MSDN: Developing Multi-tenant Applications for the Cloud, 3rd Edition
Provides good comparison between the two approaches:
Single Instance, Multi-tenant (my 1st option)
Multi Instance, Single-tenant (my 2nd option)
As it looks i will go with the Multi-tenant approach. All things considered it looks like it will require less development effort and will need less effort in maintenance. Also, my expertise lies in application development and less in system administration (which is required for truly implementing multi-instance solution).
Other reasons: there's a need to share some of the content between accounts (tenants), and this will be more easily achieved when using a single database. Also, there are future plans for the product which can utilize this solution.
Segregation of data will be done (high level):
File storage (blobs): use a separate container for each tenant (account).
Database: use tenant unique key to associate content to tenant
Cahce: use tenant unique key to generate cache keys for cached data items.
Scalability: it is easier using one instance to simply scale up its capabilities, or even move the Web Site to a dedicated virtual machine. In the future can also enhance the system to a Multi-instance, Multi-tenant structure, creating new separate instances for large tenants.
My intention is to develop and MVC app driven by WCF services.
I will then like to deploy these to Azure.
Can I go about developing my app and services without any consideration to the fact they will be hosted in Azure earlier on in the lifecycle? Or must I structure it differently?
EDIT: More specifically - am I right in saying I can develop this application just as I would prior to deciding it would be hosted in Auzre?
Based on my research and understanding, it is a better practice to consider your future implementation to azure prior to any development, however even if you later decide to move an existing application to azure, you may need to perform some modifications to your code.
please bear in mind that, Microsoft is currently offering websites in azure that can host you asp application, you may want to read more about that.
here is some links that may help you.
http://www.windowsazure.com/en-us/home/features/web-sites/
http://www.windowsazure.com/en-us/manage/services/web-sites/
The advert that appears on this page as I answer this question says "Move apps to the cloud without rewriting them".
The official position from Microsoft (who pays for the ads), is that you can migrate to Azure late in the development cycle.
The reality is:
You lose a lot of the benefits of could computing if you don't architect specifically for the cloud. This applies to any cloud platform, not just Azure.
There are likely some hidden 'gotchas' that will trip you up if you develop for normal Windows and then try and move it up to Azure. Just this morning I had a developer that was frustrated by errors on SQL Azure that didn't occur on his dev machine. The approach to SQL Azure is different to standard SQL (feature differences, throttling, etc).
There are two 'it depends' that are related:
Are you intending to use cloud services or Azure websites? Azure websites are easier to migrate because they are closer to a traditional web development approach.
Applications with lots of moving parts, or that are subject to high load, need special consideration (regardless of the target platform), so you will want to optimise for, and take advantage of, Azure specifics.
If you have a good reason not to develop specifically for Azure (such as your employers official position, platform portability, etc) then don't worry about Azure for now. If your long-term intention is to run your app on Windows Azure, then code for Azure up front — the effort to take it off Azure (lock-in) will form part of your decision later on.
I work for a growing company that has several Rails-based SaaS applications. In it's growth, the company is going after larger clients, and one of the features that has come up as a requirement for these large companies is more sophisticated user management to ease the management of their thousands of users. Right now, client membership is simplistic and completely flat, and we've been asked to replace that with a customizable nested user-group-role management system capable of modeling any (reasonable) corporate hierarchy. We expect this to be a colossal undertaking.
To complicate matters, the company is trying to grow the business into a "platform" so we've taken on a few mortar projects to glue our existing and future applications together. One of these is a user-group-role management SOA project that all of our platform applications will use via web services rather than implementing their own.
I realize that implementing user-groups is not a new problem, so I'm interested in horror and success stories, and, of course, recommendations. What's the zeitgeist? Does anyone have any recommended reading? Should we roll our own RDBMS schema to handle this system, or should we implement something like LDAP?
If you roll your own RDBMS schema, the performance and scalability is all up to your implementation. Instead you could use LDAP. You dont need to implement the LDAP (or below x.500 directory service). There are existing servers that can be used like OpenLDAP. If your company can afford you could use eDirectory from Novell or AD from MS. eDirectory supports some nice feature called dynamic groups. You may read that from here http://www.novell.com/coolsolutions/feature/5414.html.
How can i write a cloud-aware application? e.g. an application that takes benefit of being deployed on cloud. Is it same as an application that runs or a vps/dedicated server? if not then what are the differences? are there any design changes? What are the procedures that i need to take if i am to migrate an application to cloud-aware?
Also i am about to implement a web application idea which would need features like security, performance, caching, and more importantly free. I have been comparing some frameworks and found that django has least RAM/CPU usage and works great in prefork+threaded mode, but i have also read that django based sites stop to respond with huge load of connections. Other frameworks that i have seen/know are Zend, CakePHP, Lithium/Cake3, CodeIgnitor, Symfony, Ruby on Rails....
So i would leave this to your opinion as well, suggest me a good free framework based on my needs.
Finally thanks for reading the essay ;)
I feel a matrix moment coming on... "what is the cloud? The cloud is all around us, a prison for your program..." (what? the FAQ said bring your sense of humour...)
Ok so seriously, what is the cloud? It depends on the implementation but usual features include scalable computing resource and a charge per cpu-hour, storage area etc. So yes, it is a bit like developing on your VPS/a normal server.
As I understand it, Google App Engine allows you to consume as much as you want. The back-end resource management is done by Google and billed to you and you pay for what you use. I believe there's even a free threshold.
Amazon EC2 exposes an API that actually allows you to add virtual machine instances (someone correct me please if I'm wrong) having pre-configured them, deploy another instance of your web app, talk between private IP ranges if you wish (slicehost definitely allow this). As such, EC2 can allow you to act like a giant load balancer on the front-end passing work off to a whole number of VMs on the back end, or expose all that publicly, take your pick. I'm not sure on the exact detail because I didn't build the system but that's how I understand it.
I have a feeling (but I know least about Azure) that on Azure, resource management is done automatically, for you, by Microsoft, based on what your app uses.
So, in summary, the cloud is different things depending on which particular cloud you choose. EC2 seems to expose an API for managing resource, GAE and Azure appear to be environments which grow and shrink in the background based on your use.
Note: I am aware there are certain constraints developing in GAE, particularly with Java. In a minute, I'll edit in another thread where someone made an excellent comment on one of my posts to this effect.
Edit as promised, see this thread: Cloud Agnostic Architecture?
As for a choice of framework, it really doesn't matter as far as I'm concerned. If you are planning on deploying to one of these platforms you might want to check framework/language availability. I personally have just started Django and love it, having learnt python a while ago, so, in my totally unbiased opinion, use Django. Other developers will probably recommend other things, based on their preferences. What do you know? What are you most comfortable with? What do you like the most? I'd go with that. I chose Django purely because I'm not such a big fan of PHP, I like Python and I was comfortable with the framework when I initially played around with it.
Edit: So how do you write cloud-aware code? You design your software in such a way it fits on one of these architectures. Again, see the cloud-agnostic thread for some really good discussion on ways of doing this. For example, you might talk to some services on GAE which scale. That they are on GAE (example) doesn't really matter, you use loose coupling ideas. In essence, this is just a step up from the web service idea.
Also, another feature of the cloud I forgot to mention is the idea of CDN's being provided for you - some cloud implementations might move your data around the globe to make it more efficient to serve, or just because that's where they've got space. If that's an issue, don't use the cloud.
I cannot answer your question - I'm not experienced in such projects - but I can tell you one thing... both CakePHP and CodeIgniter are designed for PHP4 - in other words: for really old technology. And it seems nothing is going to change in their case. Symfony (especially 2.0 version which is still in heavy beta) is worth considering, but as I said on the very beginning - I can not support this with my own experience.
For designing applications for deployment for the cloud, the main thing to consider if recoverability. If your server is terminated, you may lose all of your data. If you're deploying on Amazon, I'd recommend putting all data that you need persisted onto an Elastic Block Storage (EBS) device. This would be data like user generated content/files, the database files and logs. I also use the EBS snapshot on a 5 day rotation so that's backed up itself. That said, I've had a cloud server up on AWS for over a year without any issues.
As for frameworks, I'm giving Grails a try at the minute and I'm quite enjoying it. Built to be syntactically similar to Rails but runs on the JVM. It means you can take advantage of all the Java goodness, like threading, concurrency and all the great libraries out there to build your web application.
Is it a good practice to develop web-service and web-site in two different languages, on two different servers? E.g. right now I create a Java web-service running on Glassfish and Ruby on Rails presentation layer running in the same server.
I'd like to leave web-service on the same server but use Ruby 1.9, running in Passenger.
Is it a good idea? I don't have experience in architecture of web-apps.
If you write a contract first web service that consumes and produces XML, you can talk to any client that can make an HTTP GET or POST request in the appropriate format. SOAP or REST, doesn't matter.
I've written Java/Spring web services that started with an XSD. A Yahoo UI RIA client took the WSDL, made an HTTP POST to send the request document, and displayed the XML response in a nice data grid.
Technically, yes you can most certainly do that. That is one of the advantages of using WS. They are interoperable.
However, I would give some consideration to the thought if someone else were to maintain it and has expertise in only one of the two platforms (RoR or Java). It is always best to ask :-)
In terms of the architecture of the system, yes, this is a "good practice". By good, I mean that it achieves the goals, does no harm, and enforces separation of concerns.
I've been developing on an architecture that has a similar structure. The user interface is .NET and uses Java Web Services. That web services then are responsible for all interaction with the persistence media, third party components, etc.
I'd say in any system you should be working to abstract your user interface logic from your business logic. It's just good separation of concerns. Using web services to do that is just one way to achieve that goal. I'd recommend using web services in the case that you will re-use those business services in other use cases in your system.
One more thing; after using two different technologies on the UI and WS for the last 8 years, I've learned that most of the challenges are organizational, not technical. For example, it's harder to find those new developers that have both skills you're looking for to maintain your app. You end up having to find an expert on one and then train them on the other technology.
It depends on how similar they are.
If your web service basically mirrors your website in functionality - then it makes a lot of sense to reuse existing code and thus to make them the same thing on the same server.
Note - this is not the same thing as entangling tiers as your views are still separate from your business logic.
From the Ruby-on-Rails perspective, the "web service" and "web-site" are often interchangeable as they are exactly the same code, with only the view-template differing (html for the website, xml for the web service).
If you build with a RESTful architecture in mind from the beginning, then you can achieve this with the minimum of duplication and with all application layers correctly decoupled.