When Java Shops Grow Up They Become Web Companies
•Download as PPT, PDF•
0 likes•360 views
SpringOne Platform 2016 Speaker: James Governor; Co-Founder, RedMonk. It’s been a long journey to Cloud Native for the Java ecosystem. Over the last 10 years or so we watched as Web company after Web company ran into scaling and management challenges that led them to adopt Java-based platforms. Meanwhile the Big Data revolution has also largely been an open source Java phenomenon. And then there’s Android of course. Java has been reinvigorated by lessons from the web – in areas such as Continuous Integration, DevOps and Microservices. Today enterprise Java shops are bringing it all together, learning from the web, adopting Java technology that has been refactored and refreshed, and tooling up to become Web Companies. Java is going to drive organisations through digital transformations. This talk will look to bring the threads together about the Java renaissance and associated cultural change.
Recommended
Recommended
More Related Content
Similar to When Java Shops Grow Up They Become Web Companies
Similar to When Java Shops Grow Up They Become Web Companies (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
When Java Shops Grow Up They Become Web Companies
- 1. 10.20.2005 Cloud for Java Natives
- 3. 3 about.us
- 4. 4
- 5. 5
- 6. 6
- 7. 7
- 8. 8
- 9. 9 when web companies grow up they turn into java shops
- 11. 11
- 12. 12
- 13. 13
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. 18 open source is the new normal
- 19. 19 nothing to see here
- 20. 20
- 21. 21
- 22. 22 “The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” Martin Fowler, Thoughtworks, March 2014
- 23. 23
- 24. 24
- 25. 25 not everyone got the memo
- 29. 29
- 30. 30 Just Culture
- 31. 31 your team may not look like this
- 32. 32 your office may not look like this
- 33. 33 but that’s ok
- 34. 34
- 35. 35
- 36. 36 Start with Culture – top down and bottom up Make open source contributions Containers – the new hotness, supporting dev pipelines Embrace distributed computing theory – CAP and 12factor Invest in people Java Make Operations pervasive, transition to Devops Refactor for service Orientation/microservices Break down large teams into small teams, loosely joined
- 37. 37
Editor's Notes
- Java remains amazingly strong and vibrant. Resurgence underpinned by Big Data and microservices. Java and Javascript as the key skills package.
- Twitter Started as monolithic rails app. “Ruby will scale” Discovering the JVM – hipster Scala Enlightenment – pragmatic use of Java Open source adoption and contribution Summer 2010, Russian President Dmitry Medvedev – twitter had to “break twitter” and hack a dedicated server to meet demand for his first tweet
- Facebook - notable “PHP shop.” 2008 needed a high scale, read intensive columnar data architecture for message search – created Cassandra. Wrote it in…Java November 2010 facebook outgrows Cassandra, adopts Hadoop, written in… Java. Cassandra adopted by Twitter, Instagram, Reddit, Netflix, Webex Also talk to yahoo and why doug cutting chose java.
- Etsy – another “PHP shop”. Begins life as a stored procedures monolith. Massive rewrite kicked off when Chad Dickerson joins in 2009. Move to devops, refactored code. Adopts Hadoop in 2009/2010 before it was even a top level Apache project. https://codeascraft.com/2010/02/24/analyzing-etsys-data-with-hadoop-and-cascading/ 2014, Cascading etc, Etsy datawarehousing team with extensive JRuby skills https://codeascraft.com/2010/02/24/analyzing-etsys-data-with-hadoop-and-cascading/ “When anyone asks what programming language to use, it is either PHP or Java because then anybody at the company can contribute.” John Allspaw SVP technical ops. 2015 http://www.nextplatform.com/2015/04/07/etsy-shows-how-to-be-just-crafty-enough-with-platforms/
- Heavy bias to shipping. Teams all work in isolation. See The Steve Yegge g+ leak All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. Anyone who doesn't do this will be fired.
- Grassroots, bottom up innovation. Cloud Native- make things easier for the engineers and developers. Get out of the way. Bias to shipping. Small teams working on *products*. Always a product focus. Teams manage their own ops. Permissionless IT.
- Netflix. All about the culture. HR is everything. Amazing Relocation package, only pay above market rate for devops. Steeped in open source. Major contributors. Started life as Java monolith running in tomcat Code shipped every 2 weeks. All of it. Ops was a separate group Decomposition smaller code bases, smaller teams, all with ops from a few teams checking code into a large monolithic application running on tens of servers to having tens of engineering teams developing hundreds of component services that run on thousands of servers. Disposability, the transition to Resilience with the expectation of breaking things. Chaos monkey, simian army.
- Current definitions are hopelessly reductive. Should *not* specify implementation details (eg container-based) CAP 12 factors CTCF Container packaged: Running in application containers as a unit of application deployment and as a mechanism to achieve high levels of resource isolation in order to improve the overall developer experience, foster code reuse and simplify operations. Dynamically managed: Actively scheduled and managed by a central orchestrating process to radically improve machine efficiency, while reducing the cost associated with maintenance and operations. Micro-services oriented: Loosely coupled with dependencies explicitly described through service endpoints with the goal of significantly increasing the overall agility and maintainability of applications Paul Fremantle 2010 - Distributed / dynamically wired. Elastic. Multi-tenant. Self-service. Granularly metered and billed. Incrementally deployed and tested. My definition- must be deployable on public cloud/standard infrastructure, expect effectively “infinite” resources, stateless/scale out, continuous deployment, microservices, DevOps, engineers for disposability.
- CFEngine: 1993 (2.0 in 2002: ML, anomaly, security) Puppet: 2005 Chef: 2009 Salt: 2011 Ansible: 2012 OpenLMI: Standards in fast-moving tech
- Conways Law "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."