Andreas Grabner has been a developer, tester, architect, and product evangelist for the past 18 years for CRM, eGovernment, testing and monitoring vendors. In his current role he helps companies injecting metrics into the end-to-end delivery pipeline to make better decisions on feature and code changes and with that also closing the feedback loops between Ops, Biz and AppDev.
Andreas has been speaking at meetups, user groups, and international conferences to share experiences and stories around architecture, agile transformation, automated testing, CI/CD and DevOps. In his spare time you can find him on the salsa dance floors. :-)
While microservices and containers promise to deliver endless scalability it doesn't mean we automatically get high performing code in these distributed application architectures. We analyzed the top performance bottleneck reasons in 2017 and see familiar patterns such as excessive service roundtrips, bad connection pooling, missing cache layers or simply sending too much data between service tiers. In this session we learn how to quickly pinpoint potential performance bottlenecks - even without executing large scale performance tests.
In 2011 we delivered 2 major releases of our on premise enterprise software. Market, technology and customer requirements forced us to change that in order to remain competitive.
Now – in 2017 - we are deploying and providing feature releases every 2 weeks for both our on premise and SaaS-based offering. We deploy 170 SaaS production changes per day and have a DevOps pipeline that allows us to deploy a code change within 1h if necessary.
To increase quality, we built and provide a DevOps pipeline that currently executes 31000 Unit ABSTRACT Integration Tests per Hour as well as 60h UI Tests per Build. Our application teams are responsible end-to-end for their features and use production monitoring to validate their deployments which allows them to find 93% of bugs in production before it impacts our end users.
In this session I explain how this transformation worked from both “Top Down” as well as “Bottom Up” in our organization. A key component was the 4 people strong DevOps Team w
I will also talk about the “dark moments” as change is never without friction. Both internally as well as with our customers who also had to get used to more rapid changes.