victorcase

I also think that it's implied, maybe like Telegram Private Chat - when you need to wait the peer to go online before complete the key exchange.

However when scale to a group with N peers.. we need to wait all of them, maybe they do waking up the peer's via Silent Notification or something like that..

Yeah it's a real fight usability vs security.

Nice, it is a good idea to plan the long run;

I don't know if weekly 1 on 1 meetings will be effective, cause in practice I will need to fit my time to "fight" for this goals and show progress; maybe troubling my sprint schedules and projects releases..

But, that's a try :) Thanks!

I will search about Tilera :) Your answer open my mind cause I hadn't thought about hardware. It got me thinking.. Are GPU architecture more friendly to be immutable or It have the same "problem" of shared memory too? And.. by the way thanks to sharing your knowledge :)

Ok in the context of - critical - constrained memory I understand;

However do you agree that is more easy to solve memory (buying new hardware) than handle with race condition? kkkk

Then, Maybe we need to think about optimize our daily data structures.. I have following a few papers about this.. e.g:

http://dl.acm.org/citation.cfm?id=2658763 http://dl.acm.org/citation.cfm?id=2993251

Hey another article at YC frontpage about saying "DO NOT MESS WITH STATE" to scale;

"Shared-memory multithreading really isn’t the future, we thought, and notably absent from all of my prior work was fixing this problem."

I'm thinking about..

Immutability is the way to scale complex systems?

Every system can be implemented as immutable by definition?

We need to look to build new data structures - like Tries - to be Immutable-friendly?

When Immutability doesn't worth it?

@diegorbaquero you should watch that https://www.youtube.com/watch?v=I7IdS-PbEgI.

The author spoke about performance and immutability-data structures like Directional Acyclic Graphs and Trie.

Nowadays we still having the scary of deploying on Fridays. What are we missing to lose this fear? Isn't DevOps mature enough? How big enterprises like Google/Facebook/Amazon.. are handling it?

Thanks for the tips; However.. We know that specific requirements are unreal for startups-like and small enterprises right? Then.. Do you have some suggestions about how techniques we can apply to handle with dynamic requirements? Maybe the real question is : What software architectures/patterns are more friendly to help Ops with it.

This is the problem that we need to solve;

"How develop/maintain a complex software and at same time keep it simple to set up without a huge bottleneck with Ops team"

If state(ful) is a problem, How about KILL Stateful? Maybe we need to (re)think about how we are handle with microservices? If true, that's is an good hypothesis to validate in a dev perspective.

Can you list at least five principles that a DEV must Learn?

Thanks for the reply, but can you explain (or provide some reference) about why not to use containers-only in production?

I know that I will add a layer of abstraction, however from a Dev perspective I have some benefit like a byte-to-byte compatible test/prod env that I haven't to worry about dependencies per example.

What you think about sandbox applications (like docker) over a PaaS can it mitigate a heterogeneous scenario?

What about containerzired deployment? Isn't Docker the silver bullet? Or at least will it allow to mitigate your issues easily?