Iām just browsing through the docs+code and I have a quick question: do you see Wolkenkit, or any of its components, working in a serverless environment? either now or in the future
Short answer
Unfortunately no.
Long answer
Unfortunately no, if we are talking about now. wolkenkit is very strict in separating your domain code from the technical infrastructure code that is required to run your domain code. Right now this technical infrastructure code is focused on making use of Docker containers, as this allows you to work not only in the cloud, but also locally, or in a classic data-center, or ā¦ you name it š
Of course it would be technically feasible and reasonable, to have another type of runtime in the future, that does not make use of Docker containers, but instead would work with some kind of FaaS solution. As the native web (the company behind wolkenkit) is a small company, we need to decide what to focus on, and unfortunately, at least right now this is not on the roadmap for the close future. I do not say that this will never be done ā it just will take time. Maybe also someone else comes up with such a runtime and enhances the wolkenkit ecosystem.
So, to cut a long story short, if now, then the answer is no. If we're talking about the future, the answer is possible, but without an ETA.
PS: I am one of the developers of wolkenkit, so please take my answer with a grain of salt.
Related
I am currently working on the topic of ci/cd. In one tutorial it is said that it is not desirable to create a "snowflake system". What is the meaning of this?
In the previous video (thanks for finding it) he defines the term: A snowflake system is a group of servers that are allegedly equal, but in reality are not. Because both the servers and the installed software is maintained and updated manually, their software starts to divert (e.g. some installation failed, some server was forgotten in a deployment round).
Snowflakes look identical from a distance, but they're never equal.
The concept (or bad practice, in this case) of manually deploying is of course not limited to the Windows command xcopy. Using linux equivalents doesn't help.
Ok. Thanks to #PMF. PMF gave me the idea to watch a previous tutorial of this and so I found out what a snowflake server is. It's about the context of the deployment to different servers. And if you do the deployment with just copying files, there can be problems. Because each server is always unique. Like snowflakes in nature. They look the same but in detail they are different or unique.
So whoever is interested or if someone has the same question in the future. This is it! :-)
To develop some boilerplate code for a dockerized solution, I want to have multiple docker-compose .dcproj projects in the same solution.
Lets say:
shared-docker-compose.dcproj - Shared services for interop, like a MQ
example-docker-compose.dcproj - Example services for testing/playground for the boilerplate.
app1-docker-compose.dcproj - The actual services for scenario 1
app#...
This should keep the velocity in development high if a part of solution needs an update. And the developer is free to consider which part of the whole solution he wants to take a look at.
Okay - not really a problem to create this project/compose files. No problem with docker, docker-compose, or any other part of the solution. Except the IDE.
Visual Studio 2017 truely struggles with multiple dcproj-files.
The behavior is different based on the order of dcproj in the .sln-file.
It takes the first found dcproj.
Unloading all other dcproj helps. But I'm not sure if this is stable.
Even if it starts, there's no guarantee the debugger tracking the requested composition. E.g. Starting dcproj#3, the debugger listens to dcproj#2.
If the first found dcproj is just plain image distributor (Like start MQ, no code, thus no 'build:'), then the compose gets up but the dev is dumped in silence.
Strangely, when there are multiple dcproj-files in the solution and you Add -> Docker Support you can choose which of them.
Or in a short: Not usable without a strong explanation to all developers. It even took a long time to get all those responsibility fragments together.
So, here's my question:
Is there any way for such a composition that works with Visual Studios .dcproj too?
Are there any recommendations for such a common scenario?
At the moment, the only way I've found was to split the solutions where the only difference is which docker-compose is included. Thank you for any ideas and for sharing your practices.
Btw, I'd like to add a dcproj-file tag. :)
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.
For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.
What language, framework, and hosting considerations should one make before starting development of a scalable web application?
The most important consideration is not to over-engineer to the point that it gets in the way of building and launching something. Analysis paralysis is the single biggest inhibitor to productivity, progress and results.
Yes, do some planning. Pick a framework. Perfection in a framework will be impossible to find because it doesn't exist, partially because you don't know what you need until you build it anyways. Chances are, if you pick something, it will be better than picking nothing.
Yes, try to pick flexible, inter-operable tools for where you see yourself going.
Yes, look for a good built-in feature set where you see yourself going in the next 6-18 Months. Trying to look beyond that is not really realistic anyways as most projects change so much anyways going towards the first release.
So, pick what you're comfortable with or what is familiar. Don't follow the crowd, do what gets you the best results, quickest, and often. Understand that you might have to change in the future. So, whatever you build now, try to use unit testing so you can re-factor if ever needed.
If what you're building is going to be super successful, it will be a great problem to have, and an easy one to work on once it's making money as you'll be able to get other talent to help you.
Share what you end up picking and why for your situation -- it helps the us learn from you too!
Don't necessarily marry yourself to one language or framework. It may be that some parts of your site work better with different languages and frameworks than others. For example, all of 37signals' sites are based on Ruby on Rails, but they recently wrote a blog post about how the underlying technology of one is actually written in Erlang now because it's much easier to do concurrency that way.
Obviously there's a level of complexity where things turn into a mishmash, but using the right tool for the job ā even if that means different tools for different jobs ā can simplify things.
Firstly on language, it largely doesn't matter. PHP, Java and .Net being probably the biggest three are all proven in the sense that they run some of the largest sites on the Web so don't listen to anyone who tells you one is more suited than any of the others.
Some might also put Ruby and Django/Python in this list. I have nothing against them but I'm not aware of any big (say top 50) sites using either.
Hosting considerations depend on how low you want to start but basically the order is:
Shared;
Virtual Private Server;
Dedicated.
Scalability will largely be about your application's design than any language, framework or provider. Efficient database schema, efficient delivery and use of Javascript/CSS and in-memory caching are all issues common to any language or framework.
Language - I'd recommend something with good frameworks and good testing libraries like Perl or Java.
Framework - it depends on what do you plan to do. If you start with a hosting that does not allow FastCGI, it is best to avoid such frameworks like Catalyst or Rails. That's why I love CGI::Application (primarily Perl, but ported to other languages too) - it can run as CGI, FastCGI or mod_perl. For development it can be run from it's own web server.
Hosting - nothing is better than you own server. It can be your own server, leased server or virtual server. But you can start with cheapest hosting and when you need more, you should be able to afford it.
It depends.
Start by looking at your requirements (Functional or user defined) (Non Functional - aspects that describe your desired system link text)
Next I would clarify what it means to have a scalable web application. Define it as test cases that can be clearly tested (must support X page views / second with response time < Y seconds).
Once I had those pieces in place I would look at what type of skills my development team can support (for the intial project and on going maintenance). Then find some case studies of applications out in the wild that use similar language or framework. If someone else has made a specific language / framework scale then chances are good that you can too.
Finally go out and look for some hosting providers that support your chosen language, framework and requirements.