Nothing here yet.
Nothing here yet.
IMHO, Go is what you need. It's designed for concurrency, networking, and high performance, and it's easy to learn. My second choice in between is Erlang stack, it is also a language born for messaging system, but considering its community and development activity, Go is better for novice to get start with.
from pylons documentation: http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introduction.html#pyramid-introduction A framework differs from a library in one very important way: library code is always called by code that you write, while a framework always calls code that you write. Using a set of libraries to create an application is usually easier than using a framework initially, because you can choose to cede control to library code you have not authored very selectively. But when you use a framework, you are required to cede a greater portion of control to code you have not authored: code that resides in the framework itself. You needn't use a framework at all to create a web application using Python. A rich set of libraries already exists for the platform. In practice, however, using a framework to create an application is often more practical than rolling your own via a set of libraries if the framework provides a set of facilities that fits your application requirements.
Automation system is a software that can make the complicated & tedious deployment process being done in an easy & centralized way. Think of running a single command or clicking on a “Deploy” button, and then all your servers will pull your latest code and update automatically. Ansible and SaltStack are two of those popular software products.
On of the common mistake I often encounter is considering too much about RESTful standard and naming convention: Is PUT better than POST in this situation? Should this API be POST .../upvote or PUT .../upvotes ? Should comments be an independent resource or a sub-resource under posts ? All these hesitations above could not make the design better, only to distract you from focusing on the core value of the API design. An API is how you think your service should communicate with others, what really matters is its readability, clarity, and maintainability, you should not care too much about whether it is RESTful-suited or not, you need to make it easy to read and understand, the parameters can reflect its calling process clearly, the data it returns could be forward/backward compatible in the future ... and so on. RESTful and SOAP and RPC are just good practices to reference, not strict standards to follow, a good designer can take the good parts and make the best API design in current situation accordingly.
Put it simply: Design your architecture, make it clear of what module your services are made of, how are they related to each other Deploy a load balancer cluster (nginx or LVS or both), run your applications behind them Choose an automation system (ansible, saltstack), automate the deployment of your application If everything above is OK, subtle performance improvements could be considered