kidwellj/findcommonground.uk
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Fixing direct link syntax

Browse source
This commit is contained in:
Holger Reinhardt 2016-08-24 23:00:35 +02:00
parent 69796a0857
commit d0a5d3fee1
2 changed files with 33 additions and 33 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

60
_posts/2016-07-02-qcon-ny-summary.md
View file

@ -32,7 +32,7 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
### Implementing Infrastructure as Code ### Implementing Infrastructure as Code
* [Description](https://qconnewyork.com/ny2016/presentation/implementing-infrastructure-code) and [slides](https://qconnewyork.com/system/files/presentation-slides/implementing_iac_-_qcon_nyc_2016.pdf) * [Description](https://qconnewyork.com/ny2016/presentation/implementing-infrastructure-code) and [slides](https://qconnewyork.com/system/files/presentation-slides/implementing_iac_-_qcon_nyc_2016.pdf)
* Website at [http://infrastructure-as-code.com]() * Website at <http://infrastructure-as-code.com>
* Motivations: * Motivations:
* speed: get something to market fast, iterate, continuously improve it * speed: get something to market fast, iterate, continuously improve it
* heavy process to reduce danger vs everything goes * heavy process to reduce danger vs everything goes
@ -43,11 +43,11 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
* Applying software engineering tools to managing the infrastructure * Applying software engineering tools to managing the infrastructure
* Unattended automation (enforces discipline, discourages ‘out-of-band’ changes * Unattended automation (enforces discipline, discourages ‘out-of-band’ changes
* Changes need to be tested as well, before doing a **DevOoops** * Changes need to be tested as well, before doing a **DevOoops**
* See [http://serverspec.org]() * See <http://serverspec.org>
* The process for applying changes is auditable (the responsible part) * The process for applying changes is auditable (the responsible part)
* Changes are tracked by commit * Changes are tracked by commit
* Automation enforces that processes are executed * Automation enforces that processes are executed
* See [http://47ron.in/blog/2015/01/16/terraform-dot-io-all-hail-infrastructure-as-code.html]() * See <http://47ron.in/blog/2015/01/16/terraform-dot-io-all-hail-infrastructure-as-code.html>
* Think about duplication * Think about duplication
* Re-use by forking: divergence vs decoupling * Re-use by forking: divergence vs decoupling
* Sharing elements avoid monoliths - optimize to simplify changes * Sharing elements avoid monoliths - optimize to simplify changes
@ -56,21 +56,21 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
### Think before you tool ### Think before you tool
* [Description](https://qconnewyork.com/ny2016/presentation/think-before-you-tool-opinionated-journey) * [Description](https://qconnewyork.com/ny2016/presentation/think-before-you-tool-opinionated-journey)
* Centralized Log Analysis: [https://prometheus.io]() * Centralized Log Analysis: <https://prometheus.io>
* Microservice dependency graphing and monitoring: [http://zipkin.io]() * Microservice dependency graphing and monitoring: <http://zipkin.io>
--- ---
### Security in cloud environments ### Security in cloud environments
* [Description](https://qconnewyork.com/ny2016/presentation/access-secret-management-cloud-services) and [Slides](https://qconnewyork.com/system/files/presentation-slides/identity_access_and_secret_management_-_ryan_lane_-_qcon.pdf) * [Description](https://qconnewyork.com/ny2016/presentation/access-secret-management-cloud-services) and [Slides](https://qconnewyork.com/system/files/presentation-slides/identity_access_and_secret_management_-_ryan_lane_-_qcon.pdf)
* Additional links for password and secret managers * Additional links for password and secret managers
* [http://docs.ansible.com/ansible/playbooks_vault.html]() * <http://docs.ansible.com/ansible/playbooks_vault.html>
* [https://gist.github.com/tristanfisher/e5a306144a637dc739e7]() * <https://gist.github.com/tristanfisher/e5a306144a637dc739e7>
* [http://cheat.readthedocs.io/en/latest/ansible/secrets.html]() * <http://cheat.readthedocs.io/en/latest/ansible/secrets.html>
* [https://github.com/DavidAnson/PassWeb]() * <https://github.com/DavidAnson/PassWeb>
* [https://passwork.me/info/enterprise/]() * <https://passwork.me/info/enterprise/>
* [https://lyft.github.io/confidant/]() * <https://lyft.github.io/confidant/>
* Detecting secrets in source code: [https://eng.lyft.com/finding-a-needle-in-a-haystack-b7e0627b01f6#.f0lazahyo]() * Detecting secrets in source code: <https://eng.lyft.com/finding-a-needle-in-a-haystack-b7e0627b01f6#.f0lazahyo>
--- ---
@ -119,11 +119,11 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
* In order to hire for cultural fit, the team has to be on the same page * In order to hire for cultural fit, the team has to be on the same page
* Lessons learnt from experimenting with culture * Lessons learnt from experimenting with culture
* Transparency breeds trust (for team and customers) * Transparency breeds trust (for team and customers)
* See [buffer.com/transparency]() * See <hhtps://buffer.com/transparency>
* Buffer transparency salary calculator * Buffer transparency salary calculator
* See [https://buffer.com/salary?r=1&l=10&e=2&q=0]() * See <https://buffer.com/salary?r=1&l=10&e=2&q=0>
* Term sheet and valuation of round A are public * Term sheet and valuation of round A are public
* See [https://open.buffer.com/raising-3-5m-funding-valuation-term-sheet/]() * See <https://open.buffer.com/raising-3-5m-funding-valuation-term-sheet/>
* It is even more important to be transparent when things don’t go well * It is even more important to be transparent when things don’t go well
* Culture is truly tested and defined during hard times * Culture is truly tested and defined during hard times
* Implementing culture for a globally distributed team * Implementing culture for a globally distributed team
@ -144,7 +144,7 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
* Culture fit -> culture contribution * Culture fit -> culture contribution
* Its the leaders job to hire for balance * Its the leaders job to hire for balance
* Hiring for culture fit assumes that culture is perfect and static * Hiring for culture fit assumes that culture is perfect and static
* See [http://diversity.buffer.com]() * See <http://diversity.buffer.com>
* A/B testing to attract different demographics * A/B testing to attract different demographics
* Taking hiring risks consciously (instead of reducing it) * Taking hiring risks consciously (instead of reducing it)
* Everyone is hired for a 45 day work bootcamp (full-time contracting period) * Everyone is hired for a 45 day work bootcamp (full-time contracting period)
@ -185,7 +185,7 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
* Fully insured * Fully insured
* Ssingle server requiring a quorum of senior engineers to unlock/unscramble * Ssingle server requiring a quorum of senior engineers to unlock/unscramble
* Multisig Vault * Multisig Vault
* [https://www.coinbase.com/multisig]() * <https://www.coinbase.com/multisig>
* Cold Storage as-a-Service (User Key, Shared Key, Coinbase Key) * Cold Storage as-a-Service (User Key, Shared Key, Coinbase Key)
* User needs paper and passphrase * User needs paper and passphrase
* m-of-n sharding of key is possible * m-of-n sharding of key is possible
@ -195,10 +195,10 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
### What they do not tell you about microservices ### What they do not tell you about microservices
* [Description](https://qconnewyork.com/ny2016/presentation/what-they-dont-tell-you-about-micro-services) and [Slides](https://qconnewyork.com/system/files/presentation-slides/qcon-microservices_talk_v7_for_web_upload.pdf) * [Description](https://qconnewyork.com/ny2016/presentation/what-they-dont-tell-you-about-micro-services) and [Slides](https://qconnewyork.com/system/files/presentation-slides/qcon-microservices_talk_v7_for_web_upload.pdf)
* See also * See also
* [http://www.slideshare.net/DanielRolnick/microservices-and-devops-at-yodle]() * <http://www.slideshare.net/DanielRolnick/microservices-and-devops-at-yodle>
* [http://www.yodletechblog.com/2016/04/25/yodle-hackathon-april-2016-edition/]() * <http://www.yodletechblog.com/2016/04/25/yodle-hackathon-april-2016-edition/>
* Good pragmatic steps for evolving from monolith to microservice architecture * Good pragmatic steps for evolving from monolith to microservice architecture
* After split Postgres started to break down with connection pooling, used an external connection pooler like [https://pgbouncer.github.io]() * After split Postgres started to break down with connection pooling, used an external connection pooler like <https://pgbouncer.github.io>
* Choose mesos/marathon * Choose mesos/marathon
* Thrift-based macro services * Thrift-based macro services
* Smart pipes vs context-aware apps * Smart pipes vs context-aware apps
@ -232,7 +232,7 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
### Lessons learned on Ubers journey into microservices ### Lessons learned on Ubers journey into microservices
* [Description](https://qconnewyork.com/ny2016/presentation/project-darwin-uber-jourbey-microservices) and [Slides](https://qconnewyork.com/system/files/presentation-slides/uber-journey_to_microservices_public.pdf) * [Description](https://qconnewyork.com/ny2016/presentation/project-darwin-uber-jourbey-microservices) and [Slides](https://qconnewyork.com/system/files/presentation-slides/uber-journey_to_microservices_public.pdf)
* See also [https://eng.uber.com/building-tincup/]() * See also <https://eng.uber.com/building-tincup/>
* Very good presentation on the motivators to break apart the monolith * Very good presentation on the motivators to break apart the monolith
--- ---
@ -240,10 +240,10 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
### The deadly sins of microservices ### The deadly sins of microservices
* [Description](https://qconnewyork.com/ny2016/presentation/seven-deadly-sins-microservices) and [Slides](https://qconnewyork.com/system/files/presentation-slides/qcon_nyc_2016_-_seven_more_deadly_sins_final.pdf) * [Description](https://qconnewyork.com/ny2016/presentation/seven-deadly-sins-microservices) and [Slides](https://qconnewyork.com/system/files/presentation-slides/qcon_nyc_2016_-_seven_more_deadly_sins_final.pdf)
* See also * See also
* [https://speakerdeck.com/acolyer/making-sense-of-it-all]() * <https://speakerdeck.com/acolyer/making-sense-of-it-all>
* [http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html]() * <http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html>
* [http://www.slideshare.net/dbryant_uk/craftconf-preview-empathy-the-hidden-ingredient-of-good-software-development]() * <http://www.slideshare.net/dbryant_uk/craftconf-preview-empathy-the-hidden-ingredient-of-good-software-development>
* [https://acaseyblog.wordpress.com/2015/11/18/guiding-principles-for-an-evolutionary-architecture/]() * <https://acaseyblog.wordpress.com/2015/11/18/guiding-principles-for-an-evolutionary-architecture/>
* Strategic goals <-> architecture principles <-> design and delivery practices * Strategic goals <-> architecture principles <-> design and delivery practices
* Neal Ford: MSA as evolutionary architecture * Neal Ford: MSA as evolutionary architecture
* Architecture is hard to change, so make architecture itself evolvable * Architecture is hard to change, so make architecture itself evolvable
@ -255,14 +255,14 @@ Here is a quick summary of my highlights of QCon New York from June 13th to June
* But getting lazy with non-functional requirements * But getting lazy with non-functional requirements
* Just Enough Software Architecture * Just Enough Software Architecture
* Recommended book [Just enough software architecture](https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104/) * Recommended book [Just enough software architecture](https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104/)
* Ebook format available through [http://georgefairbanks.com/e-book/]() * Ebook format available through <http://georgefairbanks.com/e-book/>
* Embrace BDD-Security framework for BDD-style security testing * Embrace BDD-Security framework for BDD-style security testing
* [https://www.continuumsecurity.net/bdd-intro.html]() * <https://www.continuumsecurity.net/bdd-intro.html>
* Devops * Devops
* Topologies: [http://web.devopstopologies.com]() * Topologies: <http://web.devopstopologies.com>
* Testing * Testing
* Continues Delivery: [https://dzone.com/articles/continuously-delivering-soa]() * Continues Delivery: <https://dzone.com/articles/continuously-delivering-soa>
* Service virtualization: [https://github.com/SpectoLabs/hoverfly]() * Service virtualization: <https://github.com/SpectoLabs/hoverfly>
* Hoverfly is a proxy written in Go. It can capture HTTP(s) traffic between an application under test and external services, and then replace the external services. It can also generate synthetic responses on the fly. * Hoverfly is a proxy written in Go. It can capture HTTP(s) traffic between an application under test and external services, and then replace the external services. It can also generate synthetic responses on the fly.

6
_posts/2016-08-22-state-of-our-api-strategy.md
View file

@ -26,11 +26,11 @@ But I was delighted to see your most recent enterprise architecture white papers
In the meantime we have settled on [Mashape's Kong](https://github.com/Mashape/kong) and our [own API Mgmt Portal](http://wicked.haufe.io) (one developer fulltime for 3 months) for our internal API deployments. I think you will find our portal to approach API Management from quite a different perspective than most traditional API Mgmt vendors - it fully embraces `infrastructure as code` and `immutable servers`. In our opinion it simply doesn’t make any sense to (re)introduce long running API gateway and portal servers to manage and service API’s from Microservices, which are deployed fully automated through our CI/CD pipeline. We like to think that this brings us closer to the concept of [APIOps](http://www.slideshare.net/jmusser/why-api-ops-is-the-next-wave-of-devops-62440606) - applying the same basic concepts of DevOps but to API operations. In the meantime we have settled on [Mashape's Kong](https://github.com/Mashape/kong) and our [own API Mgmt Portal](http://wicked.haufe.io) (one developer fulltime for 3 months) for our internal API deployments. I think you will find our portal to approach API Management from quite a different perspective than most traditional API Mgmt vendors - it fully embraces `infrastructure as code` and `immutable servers`. In our opinion it simply doesn’t make any sense to (re)introduce long running API gateway and portal servers to manage and service API’s from Microservices, which are deployed fully automated through our CI/CD pipeline. We like to think that this brings us closer to the concept of [APIOps](http://www.slideshare.net/jmusser/why-api-ops-is-the-next-wave-of-devops-62440606) - applying the same basic concepts of DevOps but to API operations.
You can find more details at [http://wicked.haufe.io](). You can find more details at <http://wicked.haufe.io>.
On the design governance side we also progressed rather nicely. You might find our [API Styleguide](https://github.com/Haufe-Lexware/api-style-guide) of interest - I think it represents some of the best best practices from the industry. We are planning to use [Gitbook](https://www.gitbook.com) or [ReadTheDocs](https://readthedocs.org) to publish it in a better e-book style format. We took a lot of inspiration from the [Zalando API Styleguide](http://zalando.github.io/restful-api-guidelines/). On the design governance side we also progressed rather nicely. You might find our [API Styleguide](https://github.com/Haufe-Lexware/api-style-guide) of interest - I think it represents some of the best best practices from the industry. We are planning to use [Gitbook](https://www.gitbook.com) or [ReadTheDocs](https://readthedocs.org) to publish it in a better e-book style format. We took a lot of inspiration from the [Zalando API Styleguide](http://zalando.github.io/restful-api-guidelines/).
The one remaining missing piece in our API story is an API registry. But again I am not looking for a repeat of the fallacy of a centralized UDDI or WSRR registry, but taking the Web as example and working something along [http://apis.io]() (Source code available at [https://github.com/apisio/apis.io]()). Central registries never worked, but Google does. Hence an API search engine with a choice or combination of The one remaining missing piece in our API story is an API registry. But again I am not looking for a repeat of the fallacy of a centralized UDDI or WSRR registry, but taking the Web as example and working something along <http://apis.io> (Source code available at <https://github.com/apisio/apis.io>). Central registries never worked, but Google does. Hence an API search engine with a choice or combination of
* a single git repo (containing API definitions) supporting pull requests and/or * a single git repo (containing API definitions) supporting pull requests and/or
* the ability to register commit web hooks to many git repo’s (each representing one or more API definitions) and/or * the ability to register commit web hooks to many git repo’s (each representing one or more API definitions) and/or
@ -38,7 +38,7 @@ The one remaining missing piece in our API story is an API registry. But again I
will do. I found [Zalando's API Discovery](http://zalando.github.io/restful-api-guidelines/api-discovery/ApiDiscovery.html) strategy to be very inspiring, but we might start with a Repo-based approach to learn and iterate. will do. I found [Zalando's API Discovery](http://zalando.github.io/restful-api-guidelines/api-discovery/ApiDiscovery.html) strategy to be very inspiring, but we might start with a Repo-based approach to learn and iterate.
I am still looking for contributors for that last piece of our API strategy to fall in place. But based on the already existing work in [http://apis.io]() from [3Scale](https://www.3scale.net) and the [API Evangelist](http://apievangelist.com) I think we are not that far off from where we need to be .. and if necessary we will develop the missing functionality and provide it as open source to the community. I am still looking for contributors for that last piece of our API strategy to fall in place. But based on the already existing work in <http://apis.io> from [3Scale](https://www.3scale.net) and the [API Evangelist](http://apievangelist.com) I think we are not that far off from where we need to be .. and if necessary we will develop the missing functionality and provide it as open source to the community.
I hope this gives you a good overview over the current status of the API piece in our Technology Strategy. You can follow us at [@HaufeDev](https://twitter.com/haufedev) or find up to date information on our [Developer Blog](http://dev.haufe-lexware.com). We are tentatively planning to make an announcement of our API portal in the September time frame. I hope this gives you a good overview over the current status of the API piece in our Technology Strategy. You can follow us at [@HaufeDev](https://twitter.com/haufedev) or find up to date information on our [Developer Blog](http://dev.haufe-lexware.com). We are tentatively planning to make an announcement of our API portal in the September time frame.