I’ll explain how React is moving towards a minimal API surface area. Instead of providing many framework features, React is trying to utilize patterns, paradigms and JavaScript language features to accomplish the same tasks that other frameworks have dedicated APIs for. Not all environments have these natively. We need to polyfill new an experimental features. How can we safely do that? Is it better to have a non-standard library?
ZeroVM is one of the most awesome things to happen to OpenStack Swift since the project's inception. That is, ZeroVM, through the ZeroCloud Middleware, allows you to run compute intensive workloads as close to your data as possible.
In this 90 minute workshop users will learn how to work with ZeroVM on OpenStack Swift. Specifically, we will provide an introduction to ZeroVM, some of it's use cases. From there we will show how to integrate ZeroVM with Swift and run some sample workloads.
A internal civil war has been my life for years as I've walked the razor wire separating breakers and builders.
I'd like to share my experiences presenting outside the security industry at developer conferences like Djangocon, JSConf (trackb), and RealtimeConf what it's like to be the lone security professional in a sea of builders, what it feels like, what they say, what they really care about, how not to speak to them, how to completely disrespect them, and how to fail miserably.
Extending your Rails app with some Go, Scala, Elixir or node.js sound interesting to you? The first challenge to get there is to safely share the session between your apps. Crypto is hard… but that won't prevent us from looking into how Rails sessions work and how to share them across programming languages.
1) Infrastructure services offered by multiple Openstack deployments in geographical distributed DCs need to be consolidated into a unified one;
2) Vendor agnostic and unified Openstack API is expected even when the Openstack resource pools in different DCs are provided by different vendors
3) Unified Openstack resource pooling needs to flexibly scale out from several Servers/VMs up to millions of Servers/ VMs;
4) Rolling update with minimized service interruption is expected when upgrading the Openstack Cloud OS software, SOA Restful API is preferred over RPC internal messaging interface for the orchestration & communication between different availability zones.
The answer is OpenStack Cascading solution. The speech will cover background requirements and customer value analysis, technical elaboration of OpenStack Cascading solution, and its Demo. Overview of OpenStack cascading solution can be found at wiki.openstack.org/wiki/OpenStack_cascading_solution.
1) Infrastructure services offered by multiple Openstack deployments in geographical distributed DCs need to be consolidated into a unified one;
2) Vendor agnostic and unified Openstack API is expected even when the Openstack resource pools in different DCs are provided by different vendors
3) Unified Openstack resource pooling needs to flexibly scale out from several Servers/VMs up to millions of Servers/ VMs;
4) Rolling update with minimized service interruption is expected when upgrading the Openstack Cloud OS software, SOA Restful API is preferred over RPC internal messaging interface for the orchestration & communication between different availability zones.
The answer is OpenStack Cascading solution. The speech will cover background requirements and customer value analysis, technical elaboration of OpenStack Cascading solution, and its Demo. Overview of OpenStack cascading solution can be found at wiki.openstack.org/wiki/OpenStack_cascading_solution.
