Tag Archives: software

Podcast – Baruch Sadogursky on Pipeline, Immutability, and Edge

Posted on by
Reply

Joining us this week is Baruch Sadogursky, Head of Developer Relations at JFrog. Baruch is an industry veteran in management of complex software and is a fantastic event speaker; I highly recommend attending his sessions at a future event. Short promotion for JFrog Swamp Up (May 16 – 18, 2018)

Highlights

  • Short overview of JFrog and its relationship to CI/CD pipelines
  • Discussion of immutability (shifting left) in deployment paradigms
  • Metadata and the impact of scale (Toyota Manufacturing Model)
  • How can I update software components with confidence?
  • Distributed programming and impact of edge computing

Topic                                                                                        Time (Minutes.Seconds)

Introduction                                                                            0.0 – 2.17
JFrog Artifactory                                                                    2.17 – 3.26
Pipeline (Starting)                                                                  3.26 – 7.53
Immutability (Shifting Left)                                                  7.53 – 11.51
Metadata (Surrounds the Artifact)                                     11.51 – 16.45
Impact of Scale (Excessive File Names)                           16.45 – 23.30 (Toyota Model)
Updating Software Components                                       23.30 – 28.32 (Pain is Instructional)
Edge Computing (IoT is Next Frontier)                              28.32 – 38.01
Wrap Up                                                                                 38.01 – END

Podcast Guest: Baruch Sadogursky

Baruch Sadogursky (a.k.a JBaruch) is the Developer Advocate at JFrog. His passion is speaking about technology. Well, speaking in general, but doing it about technology makes him look smart, and 17 years of hi-tech experience sure helps. When he’s not on stage (or on a plane to get there), he learns about technology, people and how they work, or more precisely, don’t work together.

He is a CNCF ambassador, Developer Champion, and a professional conference speaker on DevOps, Java and Groovy topics, and is a regular at the industry’s most prestigious events including JavaOne (where he was awarded a Rock Star award), DockerCon, Devoxx, DevOps Days, OSCON, Qcon and many others. His full speaker history is available on Lanyrd: http://lanyrd.com/profile/jbaruch/sessions/

You can follow him @jbaruch on Twitter.

Cloud Application Life Cycle

Posted on by
Reply

Or “you learn by doing, and doing, and doing”

One of the most consistent comments I hear about cloud applications is that it fundamentally changes the way applications are written.  I’m not talking about the technologies, but the processes and infrastructure.

Since our underlying assumption of a cloud application is that node failure is expected then our development efforts need to build in that assumption before any code is written.  Consequently, cloud apps should be written directly on cloud infrastructure.

In old school development, I would have all the components for my application on my desktop.  That’s necessary for daily work, but does not give me a warm fuzzy for success in production.

Today’s scale production environments involve replicated data with synchronization lags, shared multi-writer memcache, load balancers, and mixed code versions.  There is no way that I can simulate that on my desktop!   There is no way I can fully anticipate how that will behave all together!

The traditional alternative is to wait.  Wait for QA to try and find bugs through trial and error.  Or (more likely) wait for users to discover the problem post deployment.

My alternative is to constantly deploy the application to a system that matches production.    As a bonus, I then attack the deployment with integration tests and simulators.

If you’re thinking that is too much effort then you are no thinking deeply enough.  This model forces developers to invest in install and deployment automation.  That means that you will be able to test earlier in the cycle.  It means you will be able to fix issues more quickly.  And that you’ll be able to ship more often.  It means that you can involve operations and networking specialists well before production.  You may even see more collaboration between your development, quality, and operations teams.   

Forget about that last one – if those teams actually worked together you might accidently ship product on time.  Gasp!