Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

RAMP Keynote

How open source and destruction of jurisdiction enable scalability.
by

Theo Schlossnagle

on 14 August 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of RAMP Keynote

Scale
Open source & the destruction of jurisdiction make scalability
we do so through
silos
turf wars
finger pointing

most things were
open source.
Roles were
duties were

Then global
Those that were

the software...
engineers did what they had to do:
Without access to
source code...
Combining this with the
need to scale ?
Decoupled systems across (not on) their elegant boundaries.
This means jurisdictions break down.
Capable of transcending the whole stack.
bottom
to top
buy vs. build
gave us

A very old (and still very hard) question
buying is a
to developers
of the problem (and solutions)
adoption
There is really no downside to adoption, when the only available products are not open or do not exist or are crap.
buying achieves
accelerated time to market
less distraction for in-demand resources
collective product advancement
deep knowledge for non-core domains
competitive advantage
intellectual property value
internal expert knowledge
Ask yourself:
Why should I build things myself?
There are a lot of
answers.
There is one truth...
and it is rather inconvenient.
Someone has to be
If the boundaries are elegant and unbroken,

If the boundaries are violated,

That Truth is:

3
3
fixes to open-source projects per month
50MM
6

What does the

large scale Internet architecture
look like?
Rant:
libssh2
openssl ABI issues
Imagine this process with silos or without code.
More advice:
your problems:
Understand your problem space.
Understand your technology.
Understand that one
can only have
so much expertise...
"Jack of all trades; master of none."
possible.
A long time ago,
not
Speaking of history...
metaphors.
Pointer designed by Evan MacDonald from The Noun Project
running
happened.
scale
pushed
on the software in ways the vendors couldn't imagine.
(or replicate)
& thus no way to fix it
they built it themselves.
there was a
across domains.
well defined,
separated,
Rebuild the world.
Unicode in the perl source.
I can't publish packages.
Network issues.
criticalness
of
service delivery
availability
requirements
scale
requirements
relative to your industry
uniqueness
Separate
prescriptive
choose carefully.
but...
Become an expert.
"average"
4
database technologies
2
networking
vendors
server vendors
operating systems
Users
programming languages
git repos
30
30
lack of visibility
Scalable systems
are...
highly complex
highly decoupled
"huge"
tend to fail
highly
messy
open source
Buy
vs
Build
vs
Adopt
huge risk...
lack of control
over the product roadmap
to code
lack of access
lack of access
time to market
postponed
ongoing
maintenance burdens
myopic view
building achieves
except
bad
responsible.
that someone can be anyone.
being responsible requires more.
You Own What You Deploy
Scale
Acknowledgements
Hammer designed by John Caserta from The Noun Project
Engineers must know more pieces.
building is a
huge risk...
Hardware checksum errors.
Full transcript